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ABSTRACT 


This  thesis  presents  one  possible  method  of  integrating  the  DMS  and 
GBS  systems.  This  effort  is  undertaken  in  order  to  explore  how  the  DMS 
messaging  capability  can  be  extended  to  the  mobile,  tactical  user  via  a  new, 
more  robust  broadcast  subsystem.  The  Navy's  current  Fleet  Broadcast 
subsystem  is  not  prepared  to  handle  the  increased  traffic  load  expected  from  the 
conversion  to  DMS-based  messaging.  The  application  of  GBS  as  a  "next 
generation"  Fleet  Broadcast  offers  an  expansive  leap  in  tactical  broadcast 
communication  capability. 

DMS  broadcast  to  the  tactical  environment  via  GBS  is  achieved  through 
the  application  of  relatively  new,  commercially  developed  network  addressing 
and  mobile-user  routing  protocols.  Adaptation  of  a  broadcast  messaging 
capability  into  the  DMS  is  also  incorporated.  Incompatibility  issues  are  resolved 
at  the  transport  and  network  layers  instead  of  higher-layer  data  format 
conversion.  The  proposed  communications  architecture  provides  for  a  high 
data-rate  message  broadcast  system,  capable  of  carrying  DMS  traffic  to  mobile 
units. 


V 


TABLE  OF  CONTENTS 


I.  INTRODUCTION  AND  PROBLEM  OUTLINE .  1 

A.  THE  DMS  CONCEPT .  1 

1 .  Basic  X.400  /  X.500  Concepts .  2 

a.  X.400 .  2 

b.  X.500 .  4 

2.  DMS  Role  Within  the  DISN .  5 

3.  DMS  and  the  US  Navy .  6 

B.  DMS  IN  THE  CURRENT  NAVY  BROADCAST 

ENVIRONMENT . 8 

1 .  Bandwidth  Limitations .  8 

2.  Protocol  Incompatibilities .  10 

a.  TCP/IP .  11 

b.  X.400/TCP  and  Simplex  Links .  12 

c.  Mobile  User  Connectivity .  13 

3.  Security  Concerns .  14 

4.  Proposed  Solutions .  15 

C.  THESIS  SCOPE .  16 

II.  USN  FLEET  BROADCAST  . .  19 

A.  NCTAMS  PROCESSING .  19 

1.  Message  Processing .  20 

2.  Message  Transmission . 20 

B.  NAVCOMPARSII .  22 

C.  FLEET  BROADCAST  SYSTEM  LIMITATIONS .  23 

III.  GLOBAL  BROADCAST  SERVICE  (GBS) .  25 

A.  INTRODUCTION .  25 

B.  HISTORY  AND  CONCEPT  DEVELOPMENT .  26 

1 .  Direct  Broadcast  Service  (DBS) .  26 

2.  Global  Broadcast  Service  (GBS) .  27 


vii 


C.  INITIAL  GBS  DESIGN . 28 

1.  GBS  Space  Segment  .  29 

2.  Broadcast  Management  Centers . 31 

D.  CONCLUSIONS .  33 

IV.  DMS  BROADCAST  OVER  GBS . .  35 

A.  INTRODUCTION . 35 

B.  ENABLING  TECHNOLOGIES .  37 

1 .  IPv6  and  Anycast  Addressing .  37 

2.  Mobile  IP .  40 

C.  GETTING  A  DMS  MESSAGE  TO  A  TACTICAL  UNIT .  42 

1.  UnitPierside . 42 

2.  Unit  Underway . . 43 

3.  DMS  Broadcast  to  an  Embarked  Unit .  47 

4.  Shipboard  Message  Flow .  48 

D.  DOCTRINAL  ASPECTS;  SMART  PUSH,  USER  PULL .  49 

1 .  Specific  Times  to  Transmit  Messages . 50 

2.  Receipt  Confirmations .  51 

3.  Routing  Instructions  for  High  Priority  Messages .  51 

4.  Storage  of  Messages  With  Certain  Header  Data .  52 

E.  ADVANTAGES . .  52 

1 .  Simplicity .  52 

2.  Performance .  53 

3.  Security . 53 

4.  Relief  of  MILSATCOM  Burdens .  53 

5.  Near  and  Long-Term  Utility .  54 

F.  LIMITATIONS .  54 

1 .  Receipt  Acknowledgments .  54 

2.  X.500 .  54 

G.  CONCEPT  SUMMARY . 55 


viii 


V.  RECOMMENDATIONS  AND  CONCLUSIONS .  57 

A.  NEAR-TERM  RECOMMENDATIONS . 57 

1 .  Infrastructure;  World-Wide  GBS  Coverage  .  58 

2.  Accelerated  Development  /  Fielding  Of  CMTP . 58 

3.  Application  of  IPv6  on  the  DISN .  59 

4.  Application  of  Mobile  IP  Concept .  59 

5.  NCTAMS  as  DMS  and  GBS  Theater  Management  Centers .  59 

B.  LONG-TERM  RECOMMENDATIONS . 60 

C.  AREAS  REQUIRING  FURTHER  STUDY .  61 

D.  CONCLUSIONS .  63 

APPENDIX  A.  OPEN  SYSTEMS  INTERCONNECTION  (OSI) 

REFERENCE  MODEL . .  65 

APPENDIX  B.  X.400  ENVIRONMENTS,  COMPONENTS  AND 

INTERFACE  PROTOCOLS .  67 

APPENDIX  C.  DATA  THROUGHPUT  COMPARISONS  OF 

VARIOUS  SYSTEMS .  69 

LIST  OF  REFERENCES .  71 

INITIAL  DISTRIBUTION  LIST . 73 


IX 


LIST  OF  FIGURES 


1.  DON  TO  DISN  Transitional  Relationships .  5 

2.  Shipboard  Fleet  Broadcast  Subsystem .  21 

3.  Commercial  DBS  System  Block  Diagram .  27 

4.  GBS  System  Block  Diagram .  30 

5.  NCTAMS  as  a  GBS  Theater  Broadcast  Management  Center .  33 

6.  Anycast  IP  Address  Scheme .  39 

7.  Mobile  IP  Routing  Concept .  41 

8.  Proposed  Mobile  IP/Anycast  Routing  Scheme .  45 

9.  Shipboard  Data/Message  Flow . 49 


XI 


LIST  OF  TABLES 


1 .  DMS  Speed  Of  Service  Comparisons  .  4 

2.  GBS-Capable  UFO  Performance  Summary . 31 

xiii 


LIST  OF  ACRONYMS  AND/OR  ABBREVIATIONS 


ACP 

Allied  Communications  Policy 

ATM 

Asynchronous  Transfer  Mode 

AUTODIN 

Automated  Digital  Network 

BER 

Bit  Error  Rate 

BMC 

Broadcast  Management  Center 

CINC 

(Theater  Unified)  Commander  In  Chief 

CMTP 

Connectionless  Message  Transport  Protocol 

CONUS 

Continental  United  States 

COO 

Concept  Of  Operations 

DBS 

Direct  Broadcast  Service 

DCP 

Distributed  Communications  Processor 

DDN 

Defense  Data  Network 

DISA 

Defense  Information  Systems  Agency 

DISN 

Defense  Information  Systems  Network 

DMS 

Defense  Message  System 

DoD 

Department  of  Defense 

DoN 

Department  of  the  Navy 

EBCDIC 

Extended  Binary  Coded  Decimal  Interchange  Code 

EDAC 

Error  Detection  and  Correction 

EHF 

Extremely  High  Frequency 

email 

electronic  mail 

EMCON 

Emissions  Control 

FEC 

Forward  Error  Correction 

FLTBCST 

Fleet  Broadcast 

GBS 

Global  Broadcast  Service 

GCCS 

Global  Command  and  Control  System 

GENSER 

General  Service  (message) 

GHz 

Giga-Hertz 

GOSIP 

Government  Open  Systems  Interconnect  Profile 

HF 

High  Frequency 

IP 

Internet  Protocol 

IPv6 

Internet  Protocol  version  6 

ISDN 

Integrated  Services  Digital  Network 

ITU 

International  Telecommunications  Union 

JANAP 

Joint  Army,  Navy,  Air  Force  Publication 

JCS 

Joint  Chiefs  of  Staff 

JWID 

Joint  Warrior  Interoperability  Demonstration 

LAN 

Local  Area  Network 

LANT 

Atlantic  (ocean) 

MFI 

Multi-Function  Interpreter 

MHS 

Message  Handling  System 

MHz 

Mega-Hertz 

MILSATCOM 

Military  Satellite  Communication 

XV 


MISSI 

Multilevel  Information  Systems  Security  Initiative 

MNS 

Mission  Need  Statement 

MPEG 

Moving  Pictures  Expert  Group 

MTA 

Message  T  ransfer  Agent 

MTS 

Message  Transfer  System 

NAVCOMPARS 

Navy  Communications  Processing  and  Routing  System 

NAVCOMSTA 

Naval  Communications  Station 

NAVMACS 

Naval  Automated  Communications  System 

NCP 

Navy  Communications  Processing  and  Routing  System 

NCTAMS 

Naval  Computer  and  Telecommunications  Area  Master  Station 

NIPRNET 

Non-classified  Internet  Protocol  Routed  Network 

NRO 

National  Reconnaissance  Office 

NSA 

National  Security  Agency 

ORD 

Operational  Requirements  Document 

OSI 

Open  Systems  Interconnection 

PAG 

Pacific  (ocean) 

QPSK 

Quadrature-Phase  Shift  Keying 

SCI 

Special  Compartment  Information 

SHF 

Super  High  Frequency 

SIPRNET 

Secret  Internet  Protocol  Routed  Network 

SMTP 

Simple  Mail  T ransport  Protocol 

SPAWAR 

Space  and  Naval  Warfare  Systems  Command 

TAC-3 

Tactical  Advanced  Computer  (version)  3 

TACINTEL 

Tactical  Intelligence 

TCP 

Transmission  Control  Protocol 

TDM 

Time  Division  Multiplex 

TS 

Top  Secret 

UA 

User  Agent 

UDP 

User  Datagram  Protocol 

UFO 

UHF  Follow-On  (satellite) 

UHF 

Ultra  High  Frequency 

USMTF 

United  States  Message  Text  Format 

USSB 

United  States  Satellite  Broadcasting  (Corporation) 

VLF 

Very  Low  Frequency 

WAN 

Wide  Area  Network 

XVI 


ACKNOWLEDGMENT 


The  author  would  like  to  acknowledge  the  following  persons  for  their  guidance, 
support  and  patience  during  the  completion  of  this  thesis: 


LCDR  Kathleen  Bryant,  SPA  WAR  PMW  172-D3E 
Mr.  Sheldon  Arey,  MITRE  Corp. 

Dr.  Roy  Axford,  NCCOSC  RDTE  DIV  841 
Mr.  Bruce  Miller,  NTC 


XVII 


EXECUTIVE  SUMMARY 


DoD  messaging  is  moving  to  the  Defense  Message  System  (DMS).  DMS  is  a 
hardware,  software  and  information  management  solution  designed  to  meet  all  DoD 
messaging  requirements  and  allow  for  interoperable  electronic  messaging.  In  a  most 
basic  sense,  DMS  can  be  viewed  as  the  set  of  components  via  which  a  DoD-wide 
electronic  mail  (email)  service  will  be  established.  Military  messaging  requirements, 
met  in  the  past  by  service-specific  (and  often  incompatible)  systems,  will  now  be 
incorporated  into  a  DoD-wide  multimedia  email  environment.  Beyond  the  changes  in 
messaging  standards,  DMS  alters  the  way  DoD  conducts  its  messaging  and  over  what 
links  these  new  messages  are  passed.  DoD  DMS  transition  efforts  are  aimed  at 
complete  replacement  of  the  current  Automated  Digital  Network  (AUTODIN) 
message-switched  network  by  the  year  2000. 

However,  while  shore-based  users  can  rely  on  such  infrastructure  technologies 
as  Integrated  Services  Digital  Network  (ISDN),  Asynchronous  Transfer  Mode  (ATM), 
commercially-standardized  network  protocols  and  high-throughput  physical  links  to 
increase  their  DMS  performance  and  connectivity,  these  same  technologies  have  not 
effectively  been  applied  at  the  mobile,  tactical  level.  Furthermore,  the  Navy  must 
contend  with  DMS  connectivity  to  highly  mobile  subscribers,  who  also  function  as  the 
basic  element  of  the  naval  operational  force,  namely  ships.  Complicating  the  Navy's 
DMS  implementation  efforts  is  the  fact  that  tactical  units  must  often,  due  to  bandwidth 
limitations  and  operational  security  (i.e.  Emissions  Control  -  EMCON),  commit  solely  to 
a  "receive  only"  communication  link  known  as  the  Fleet  Broadcast.  It  is  expected  that  a 
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broadcast  capability  must  be  maintained  by  the  Navy's  emerging  DMS  infrastructure. 
However,  the  Navy's  Fleet  Broadcast  subsystem  is  ill-equipped  to  handle  DMS 
message  traffic.  Increased  throughput  requirements,  incompatible  protocols,  security 
concerns  and  system  management  issues  must  be  addressed  prior  to  effective  DMS 
connectivity  in  a  broadcast  mode.  Many  technical  and  managerial  aspects  of  the  Fleet 
Broadcast  must  be  modernized  if  it  is  to  become  a  seamless  extension  of  the  DMS 
infrastructure  into  the  tactical  environment.  Current  proposal  for  resolving  the 
limitations  of  applying  DMS  over  broadcast  links  call  for  the  translation  of  the  DMS 
message  back  to  an  AUTODIN  format  prior  to  transmission  over  all  MILSATCOM 
communication  systems,  both  duplex  and  broadcast.  This  is  admittedly  a  short-term 
solution. 

High  data-rate  direct  broadcast  services,  recently  perfected  by  civilian  industry, 
represent  a  unique  and  timely  opportunity  for  the  US  military  to  vastly  improve  its  data 
dissemination  architecture.  In  an  attempt  to  effectively  apply  this  emerging  technology, 
the  US  military  is  developing  a  new  satellite-based  data  dissemination  system,  based 
on  similar  commercial  systems,  known  as  the  Global  Broadcast  Service  (GBS).  The 
application  of  GBS  as  a  "next  generation"  Fleet  Broadcast  offers  an  expansive  leap  in 
tactical  broadcast  communication  capability.  Furthermore,  this  broadcast  technology 
can  be  effectively  adapted  to  the  DMS  architecture.  In  this  manner,  not  only  is  the 
Navy's  message  broadcast  capability  expanded,  but  the  overall  load  on  duplex 
MILSATCOM  systems  is  reduced. 

DMS  broadcast  to  the  tactical  environment  via  GBS  and  the  integration  of  this 
capability  into  the  DISN  requires  the  application  of  relatively  new  network  addressing 
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and  mobile  user  routing  protocols.  Adaptation  of  the  current  DMS  messaging  protocols 
is  also  required.  The  proposed  communications  architecture  provides  for  a  high 
data-rate  message  broadcast  system,  capable  of  carrying  DMS  traffic  to  mobile  units. 
The  proposed  system  offers  a  near-term  tactical  DMS  utility  while  more  robust  duplex 
links  are  developed.  It  also  identifies  the  frame-work  for  a  long-term  DMS  "Fleet 
Broadcast"  link. 

Ultimately,  DMS  will  be  implemented  in  all  DoD  environments:  tactical,  strategic, 
fixed  and  mobile.  However,  while  DMS  efforts  are  aimed  at  providing  multimedia 
messaging  capabilities,  the  networks  used  to  pass  these  messages  are  not  being 
expanded  to  meet  the  new  requirements.  This  thesis  attempts  to  present  one  possible 
method  of  integrating  the  DMS  and  GBS  systems.  This  effort  is  undertaken  in  order  to 
explore  how  the  DMS  messaging  capability  can  be  extended  to  the  mobile,  tactical  user 
via  a  new,  more  robust  broadcast  subsystem.  While  a  duplex  DMS  connectivity  to 
tactical  units  is  certainly  essential,  this  thesis  focuses  on  an  architecture  and  concept  of 
operations  for  a  high  data-rate,  DMS  capable  broadcast  system. 
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I.  INTRODUCTION  AND  PROBLEM  OUTLINE 


A.  THE  DMS  CONCEPT 

The  Department  of  Defense  (DoD)  is  currently  transitioning  from 
service-specific  (and  often  incompatible)  messaging  systems  to  the  Defense 
Message  System  (DMS).  The  DMS  complies  with  the  X.400/X.500  international 
standards  for  digitally  switched  message^  (non-voice)  traffic.  DMS  is  a  hardware, 
software  and  information  management  solution  designed  to  meet  all  DoD 
messaging  requirements  and  allow  for  interoperable  electronic  messaging.  In  a 
most  basic  sense,  DMS  can  be  viewed  as  the  set  of  components  via  which  a 
DoD-wide  electronic  mail  (email)  service  will  be  established.  Ultimately,  DMS  will 
be  implemented  in  all  DoD  environments:  tactical,  strategic,  fixed  and  mobile. 
Basic  DMS  requirements,  as  outlined  by  the  Assistant  Secretary  of  Defense  for 
C3I,  include:  [Ref.  1] 

•  support  for  exchange  of  electronic  messaging  at  all  classification  levels 

•  maintain  a  high  level  of  reliability  and  availability 

•  Interoperate  with  current  messaging  systems  until  fully  implemented 

•  field  a  single  system  that  supports  both  formal  (organizational)  and 
informal  (individual)  message  communications. 

DMS  long-term  goals  include  the  phasing  out  of  existing  messaging  systems,  the 
automated  extension  of  email  services  to  the  end  user,  and  increased 
messaging  connectivity  throughout  DoD  with  expanded  capabilities  such  as  text, 

^  Throughout  this  thesis  "message  traffic"  refers  to  non-voice  organizational 
communications  of  an  official  nature  or  of  general  operational  interest. 
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video,  images  and  pre-recorded  voice.  The  DoD's  ultimate  DMS  goal,  as  stated 
on  the  DMS  World  Wide  Web  home  page,  is  a  secure,  accountable,  reliable 
writer-to-reader  messaging  system  for  the  warfighter  at  a  reduced  cost. 

1.  Basic  X.400/X.500  Concepts 

An  in-depth  review  of  all  DMS  functions,  components  and  structure  is  not 
undertaken  in  this  thesis^.  However,  some  specific  aspects  and  technologies 
which  form  the  basis  of  DMS  and  the  X.400/X.500  email  protocols  are  reviewed 
in  the  following  subsections. 

DMS  is  based  on  the  1988  X.400  email  protocol  and  the  Open  Systems 
Interconnection  (OSI)  network  model,  which  divides  the  various  processes 
involved  in  electronic  data  transfer  into  seven  distinct  layers  (refer  to  Appendix 
A).  These  layers  are  each  responsible  for  specific  aspects  of  data  manipulation 
and  network  interaction. 

a.  X.400 

The  X.400  email  protocol  is  composed  of  three  environments  (refer 
to  Appendix  B).  The  inner-most  environment  is  the  mail  transfer  system  (MTS) 
which  provides  the  basic  service  of  moving  messages  from  one  place  to  another. 
It  consists  of  Message  Transfer  Agents  (MTAs)  that  communicate  with  each 
other  via  an  application  protocol  known  as  PI .  The  lower-level  network  and 
transport  protocols  used  between  MTAs  are  not  specified  by  X.400.  PI  assumes 

^  A  comprehensive  DMS  technical  overview  can  be  found  in  Ref.  [3]. 
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the  presence  of  these  lower-level  protocols,  but  makes  little  demand  on  them; 
this  allows  X.400  packets  to  be  carried  over  physical  links  by  various  routing  and 
transport  protocols.  This  lack  of  reliance  on  lower  protocols  is  beneficial  when 
applied  to  the  vast  majority  of  networks,  which  are  based  on  duplex  connectivity: 
but  causes  problems  when  applied  to  a  simplex  (one-way)  communication  link. 

The  second  environment,  called  the  message  handling  system 
(MHS),  incorporates  user  agents  (UA)  which  act  as  the  user's  direct  email 
interface  mechanism.  A  UA  allows  the  user  to  create,  edit,  send,  receive  and 
view  X.400  email  messages.  Personal  computers  are  the  most  common  UA 
implementation.  Several  UAs  can  be  connected  to  a  single  MTA.  The  protocols 
used  to  connect  UAs  to  MTAs  are  known  as  P3/P7.  The  final,  outer-most,  layer 
incorporates  the  users  and  the  type  of  network  system  environment  (e.g.,  single 
unit,  squadron,  organization)  over  which  the  MHS  is  implemented. 

Although  DMS  will  maintain  the  DoD's  five  levels  of  priority  for 
message  delivery,  these  levels  will  be  mapped  to  the  three  precedence  levels 
inherent  in  X.400  for  actual  transport.  Table  1  compares  the  speed  of  delivery 
service  for  X.400  and  the  current  DoD  message  precedence  and  delivery  criteria. 
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Table  1.  DMS  Speed  of  Service  Comparisons.  After  Ref  [2]. 


b.  X.500 

X.400  addresses  are  composed  of  long  attribute  and  value  strings 
(e.g.,  country:  l/S/A,  enterprise:  US  Navy,  organization:  CINCLANTFLT, 
suborganization:  Second  Fleet,  unit:  USS  SHIP,  title:  CO)^  Because  these 
strings  are  difficult  to  remember,  a  user-accessible  central  store  of  X.400 
addresses  was  required.  This  address  database  is  implemented  with 
international  standards  known  as  the  X.500  series  data  store  protocols.  These 
protocols  allow  users  to  query  a  distributed  directory  for  any  data  they  require 
(e.g.,  X.400  email  addresses  and/or  demographic  data). 


As  an  example,  the  Simple  Mail  Transfer  Protocol  (SMTP)  used  extensively 
on  the  commercial  Internet  uses  a  simple  string  of  domain,  subnetwork,  network 
and  user  identifiers,  where  the  user's  identifying  script  is  separated  frorri  the 
network  addresses  by  an  An  SMTP  address  looks  like: 
user@subnet.  network.domain 
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2. 


DMS  Role  Within  the  DISN 


Beyond  the  changes  in  messaging  standards,  DMS  alters  the  way  DoD 
conducts  its  messaging  and  over  what  links  these  new  messages  are  passed. 
Figure  1  depicts  the  transitional  relationships  between  the  current  Defense  Data 
Network  (DDN)  communication  subsystems  and  the  proposed  integrated 
communication  architecture  commonly  referred  to  as  the  Defense  Information 
Systems  Network  (DISN).  DMS  will  act  as  the  message  traffic  component  of  the 
DISN.  DoD  DMS  transition  efforts  are  aimed  at  complete  replacement  of  the 
current  Automated  Digital  Network  (AUTODIN)  message-switched  network  by 
the  year  2000  [Ref.  2].  All  DISN  (and  therefore  DMS)  transition  efforts  are 
coordinated  by  the  Defense  Information  Systems  Agency  (DISA).  Each  service 
maintains  a  DMS  Program  Office  chartered  to  implement  DMS  transition 
components. 


PRE  1992 


TRANSITION  PERIOD:  1992-1999 


GOAL  FOR  2000 


DDN 


DSNET3 


JWICS 


DISN 


Unclassified  But  Sensitive  Data  ^ 

SECRETData  ^ 

DSNET 1  , 

DSNET2  , 

NIPRNET 


SIPRNET 


TS/SCIData 


J3VICS 


all  operational  &  personal  message  traffic 


Figure  1.  DDN  to  DISN  Transitional  Relationships.  After  Ref  [3]. 
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3. 


DMS  and  the  US  Navy 


There  are  approximately  1 1 ,235  communication  sites'*  in  the  US  Navy, 
distributed  over  273  land-based  commands  and  369  ships.  Additionally,  the 
Navy  provides  communication  support  to  approximately  390  non-DoN 
organizations  [Ref.  4].  There  is  no  official  documentation  of  the  amount  of  intra- 
and  inter-DoN  email  communications  over  the  commercial  Internet.  However,  a 
1 994  study  indicated  that  at  least  1 8  different  types  of  proprietary  email  systems 
are  in  operation  throughout  DoN  activities  and  commands  [Ref.  4].  The  Navy's 
DMS  solution  proposes  to  standardize  these  systems  and  provide  email 
connectivity  to  both  shore  and  sea-based  operators  with  the  same  elements  of 
service  denoted  for  all  DMS  users.  However,  while  shore-based  users  can  rely 
on  such  infrastructure  technologies  as  ISDN  (Integrated  Services  Digital 
Network),  ATM  (Asynchronous  Transfer  Mode),  commercially  standardized 
protocols  and  high-throughput  physical  links  to  increase  their  DMS  performance 
and  connectivity,  these  same  technologies  have  not  effectively  been  applied  at 
the  mobile,  tactical  level. 

Furthermore,  the  Navy  must  contend  with  DMS  connectivity  to  highly 
mobile  subscribers,  who  also  function  as  the  basic  element  of  the  naval 
operational  force,  namely  ships.  Bandwidth  limitation,  both  at  the  receive  station 


Communication  "site"  is  defined  here  as  a  dedicated  communication  center, 
transmit/receive  facility  or  station.  Theoretically,  DMS  expands  this  definition  to 
include  the  individual  email  user. 
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(ship)  and  relay  satellite,  is  by  far  the  most  constraining  factor  in  the  full 
implementation  of  DMS  connectivity  to  all  US  Navy  subscribers  [Ref.  4]. 

The  Navy  must  also,  in  its  tactical  DMS  implementation  efforts,  meet 
several  required  operational  messaging  characteristics,  defined  by  DISA.  which 
denote  the  base  performance  standards  expected  of  all  DMS  implementation 

efforts  within  DoD  [Ref.  5].  They  include: 

•  Maintain  a  probability  of  message  loss  less  than  1  out  of  100  million 

•  Provide  for  changing  traffic  loads,  accommodate  peak  traffic  volumes  in 
times  of  crises  (150%  of  peacetime  rates)  and  war  (200%  of 
peacetime  rates) 

•  Ensure  writer-to-reader  system  availability  of  at  least  98.5% 

•  Maintain  25%  system  growth  allowance 

•  Store  at  least  1 0  days  of  organizational  messages 

•  Maintain  storage  capacity  for  30  days  of  audit  information 

•  Guarantee  organizational  message  delivery  of  at  least  99.99%. 

Complicating  the  Navy's  DMS  implementation  efforts  is  the  fact  that 
tactical  units  must  often,  due  to  bandwidth  limitations  and  operational  security 
(i.e,.  Emissions  Control  -  EMCON),  commit  solely  to  a  "receive  only" 
communication  network  known  as  the  Fleet  Broadcast  (FLTBCST).  It  is 
expected  that  a  broadcast  capability  must  be  maintained  by  the  Navy's  emerging 
DMS  infrastructure.  The  technical  and  information  management  details  of  the 
Navy's  current  Fleet  Broadcast  system  are  reviewed  in  Chapter  II  of  this  thesis. 
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B.  DMS  IN  THE  CURRENT  NAVY  BROADCAST  ENVIRONMENT 

New  messaging  architectures  and  higher  bandwidth  transmission 
subsystems  are  the  key  to  the  world-wide  communication  infrastructure  outlined 
in  the  Navy's  COPERNICUS  concept.  DMS  is  viewed  by  its  proponents  as  a 
critical  springboard  for  future  application  of  information  management 
technologies  within  the  DoN  and  DoD.  Moreover,  any  new  information  system 
demands  a  review  of  how  to  best  organize,  manage  and  disseminate  that 
information.  This  is  especially  true  of  DMS,  where  not  only  is  equipment  to  be 
replaced,  but  where  the  entire  concept  of  how  the  DoD  accomplishes  its 
message  communications  will  be  altered. 

Current  Navy  fleet  broadcast  architectures  cannot  meet  the  new  DMS 
requirements.  Increased  throughput  requirements,  incompatible  protocols, 
security  concerns  and  system  management  issues  must  be  addressed  prior  to 
effective  DMS  connectivity  in  a  broadcast  mode.  These  points  are  detailed 
below. 


1.  Bandwidth  Limitations 

The  primary  causes  of  communication  backlogs  within  the  current 
FLTBCST  are  the  slow  transmission  rates  of  the  satellite  subsystems  (maximum: 
9600  bps).  Average  Navy  message  size  was  determined  in  1990  to  be  2,544 
bytes  [Ref.  7].  DMS  will,  without  doubt,  increase  average  message  size  due  to: 

•  the  higher  overhead  associated  with  the  X.400  protocols 

•  an  expanded  messaging  capability  (e.g.,  multimedia  attachments) 
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•  overhead  added  by  application  of  security  protocols 

•  other  reasons  presented  in  detail  later  in  this  thesis. 

The  ease  of  use  and  widespread  application  of  DMS  can  also  be 
expected  to  increase  the  number  of  messages  sent  between  users,  in  much  the 
same  manner  as  the  recent  explosion  of  email  use  over  the  commercial  Internet. 
The  current  throughput  capabilities  (measured  in  bps)  of  the  DoD's  Military 
Satellite  Communication  (MILSATCOM)  systems  are  far  less  than  what  is 
required  for  effective  DMS  connectivity  to  tactical  units. 

The  bandwidth  expansion  capacity  of  current  shipboard  systems  are 
stifled,  mostly  due  to  limitations  in  receive  antenna  size.  Use  of  commercial  C 
and  Ku-band  satellites,  with  associated  large  (2-3  meter)  receive  antennas  may 
alleviate  bandwidth  constraints  on  large  platforms  such  as  aircraft  carriers  and 
amphibious  ships,  but  it  does  not  address  the  needs  of  smaller  escorts  and 
submarines  with  their  limited  antenna  support  structures.  Some  evolving 
antenna  technologies,  such  as  phased  array  antennas,  may  well  alleviate  the 
limited  antenna  space  concerns  on  smaller  ships,  but  widespread  application  of 
these  technologies  will  not  occur  in  the  near  term. 

Smaller,  higher  bandwidth,  satellite  transmission  systems  must  be 
examined  and  applied  to  the  Navy's  DMS  tactical  environment  as  message  size 
and  traffic  load  increase.  When  variation  in  antenna  size  and  receiver  sensitivity 
is  limited,  increased  data  throughput  can  be  obtained  only  by  using  higher 
frequency  bands,  increasing  satellite  downlink  transmission  power  or  application 
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of  higher  data  compression  ratios.  A  recently  developed  broadcast  satellite 
system,  which  meets  these  demands,  is  the  focus  of  Chapter  III  of  this  thesis. 

2.  Protocol  Incompatibilities 

As  previously  presented,  DMS  is  based  on  the  1988  X.400  email  protocol 
and  the  Open  Systems  Interconnection  (OSI)  model  (refer  to  Appendix  A). 

Layers  1  through  3  involve  the  physical  transport,  addressing  and  routing  of  the 
datagrams,  while  layers  4  through  7  (of  which  X.400  is  a  part)  are  responsible  for 
higher  levels  of  datagram  sequencing,  error  detection/correction,  formatting  and 
presentation  to  the  user.  DMS  messages,  although  formatted  with  the  X.400 
protocol,  are  predominately  carried  over  the  Transmission  Control  Protocol  / 
Internet  Protocol  (TCP/IP)  based  NIPRNET.  TCP/IP  is  a  set  of  transport, 
addressing  and  routing  protocols  (equivalent  to  OSI  layers  3-4)  developed  by 
DoD  for  use  on  the  Internet.  They  remain  the  most  common  set  of  network 
interconnection  protocols  on  the  Internet. 

The  general  benefit  of  the  OSI  model  is  a  strict  division  of  networking 
responsibilities.  Each  layer  is  wholly  responsible  for  very  specific  aspects  of  data 
manipulation  and  network  interaction.  Each  layer  interacts  only  with  the  layer 
immediately  below  and  above  it.  However,  when  a  network  connection  is  made 
between  two  nodes,  each  layer  located  at  one  end-node  also  communicates 
(exchanges  specific  data)  with  its  counter-part  on  the  other  end  node  (true  for  all 
layers  above  the  network  layer).  This  ability  to  establish  a  duplex  link  and 
exchange  data  back  and  forth  between  nodes  is  known  as  connection-oriented 
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connectivity.  The  connection-oriented  requirements  inherent  in  the  application  of 
X.400  over  TCP/IP  netw/orks  increases  the  number  of  transmitted  data  bits 
required  to  affect  a  message  transfer. 

a.  TCP/IP 

The  Internet  Protocol  (IP)  is  designed  for  use  in  interconnected 
computer  communication  networks.  IP  provides  for  transmitting  blocks  of  data, 
called  datagrams,  from  sources  to  destinations,  where  sources  and  destinations 
are  identified  by  fixed-length  numerical  addresses.  IP  also  provides  for 
fragmentation  and  reassembly  of  long  datagrams.  Each  datagram  is  treated  as 
an  independent  entity  unrelated  to  any  other  datagram.  IP  does  not  provide 
reliable  communications.  There  are  no  acknowledgments  and  there  is  no  error 
correction  for  datagrams,  only  a  header  checksum.  There  is  no  facility  for  the 
retransmission  of  lost  datagrams  or  for  controlling  the  flow  of  datagrams. 

All  reliability,  error  control,  retransmission  and  sequencing  actions 
are  carried  out  by  the  next  higher  layer  in  this  model,  known  as  the  Transmission 
Control  Protocol  (TCP).  TCP  insures  that  the  higher  application  layers  receive 
datagrams  that  are  error-free  and  in  correct  sequence.  However,  TCP  can  only 
operate  effectively  in  a  connection-oriented  network  environment.  This  means 
that  TCP  expects  the  destination  node  to  send  acknowledgments  whenever  it 
successfully  receives  a  datagram.  All  datagrams  (e.g.,  X.400  message  packets) 
must  therefore  travel  along  a  circuit  path  in  which  both  the  sending  node  and  the 
intended  receiving  node  can  communicate  with  each  other.  Basically,  a  two-way 
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data  exchange  session  must  be  established  and  maintained  between  the 
sending  node  and  the  receiving  node  in  order  for  datagrams  to  be  passed. 

b.  X.400/TCP  and  Simplex  Links 

During  an  X.400  message  transfer  session,  both  the  P1  protocol 
and  the  TCP  layer  of  the  originating  node  communicate  directly  with  their 
respective  counterparts  on  the  recipient  node.  Basically,  the  originating  MTA's 
P1  expects  to  receive  acknowledgment  from  the  recipient  MTA  prior  to  and 
during  message  transfer.  These  acknowledgment  datagrams  are  in  addition  to 
the  retransmission  requests  commonly  sent  back  and  forth  between  the  TCP 
layers.  This  duplication  of  effort  does  not  pose  immediate  concern  if  the  two 
network  nodes  maintain  a  duplex  connectivity.  In  that  case,  the  two  protocols 
(P1  and  TCP)  can  each  request  and  receive  individual  acknowledgments. 
However,  this  duplication  of  effort  does  add  to  link  congestion  since  an 
undeterminable  number  of  acknowledgment  packets  are  required  to  affect  a 
datagram  transfer.  Furthermore,  this  duplication  of  effort  also  presents  problems 
when  applied  to  simplex  links  where  the  protocols  cannot  exchange  data. 
Solutions  which  satisfy  the  acknowledgment  needs  of  both  the  P1  and  the 
transport  layer  (TCP)  must  be  incorporated  to  effect  a  successful  message 
transaction  over  a  broadcast  link. 

The  need  to  satisfy  the  acknowledgment  requirements  of  both  the 
P1  and  TCP  protocols  represents  the  primary  hindrance  to  the  application  of 
DMS  in  "connectionless"  network  architectures,  of  which  (simplex)  broadcast 
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communications  are  a  part.  In  order  to  satisfy  the  needs  of  the  transport  layer 
over  a  simplex  link,  (e.g.,  over  Fleet  Broadcast)  datagrams  must  contain  both 
packet  sequence  data  and  imbedded  error  detection  and  correction  (EDAC) 
schemes,  known  as  forward  error  correction  (FEC);  both  require  additional  data 
bits.  These  additional  bits  are  critical  since  the  receiving  node  (e.g.,  a  ship's 
MTA)  cannot  immediately  send  back  requests  for  packet  retransmission  if  it  finds 
an  error  or  fails  to  receive  a  packet.  However,  with  DMS,  the  acknowledgment 
demands  of  the  originating  MTA's  P1  must  also  be  met,  since  it  expects  to 
interact  (exchange  data)  directly  with  the  P1  layer  of  the  receiving  MTA.® 

c.  Mobile  User  Connectivity 

The  DISN  lacks  a  capability  which  is  paramount  to  successful, 
seamless  integration  of  US  Navy  tactical  units  into  its  network.  Specifically, 
TCP/IP,  as  presently  incorporated  by  the  NIPRNET,  cannot  effectively  route 
datagrams  to  units  unless  they  maintain  a  network  (DISN)  interface  via  the  same 
network  host.  The  IP  protocol  ties  the  physical  location  of  a  node  with  its 
network  connection.  If  a  node  leaves  its  network  and  then  regains  connectivity 
via  another  host  interface  (e.g.,  a  user  leaves  their  home  office  and  wishes  to 
receive  all  their  email  via  a  network  in  another  city),  it  must  be  assigned  a  new  IP 
address  by  the  new  network  interface  host.  This  new  IP  address  must  be 
updated  by  all  network  routers  and  nodes  in  order  for  the  mobile  node  to 

®  This  need  for  application-layer  connectivity  is  not  unique  to  DMS.  Most 
applications  designed  for  use  on  networks  rely  on  duplex  links  over  which  to 
coordinate  information  transfer. 
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continue  receiving  datagrams.  In  Navy  terms,  a  ship  transitioning  from  the 
Atlantic  to  the  Mediterranean  must  be  assigned  a  completely  new  IP  address. 
This  new  address  must  then  be  broadcast  to  all  DISN  users  and  routers  before 
seamless  re-routing  of  traffic  to  the  ship  can  occur.  Message  originators  which 
use  the  ship's  old  IP  address  will  be  unable  to  effect  a  successful  connectivity 
with  it.  If  IP  addresses  change  often  and  new  address  updates  are  not  quick 
enough,  then  network  connectivity  at  the  routing  (IP)  layer  can  easily  be  lost. 

The  scalability  and  seamless  integration  of  such  a  mobile-user  capability  into  a 
network  as  large  as  the  DISN  is  not  a  trivial  concern. 

3.  Security  Concerns 

The  DISN,  unlike  AUTODIN,  is  not  based  on  a  secure  network 
infrastructure.  The  new  DISN  packet-switched  architecture  is  divided  between 
two  sublinks:  the  NIPRNET  and  the  SIPRNET  (Secure  Internet  Protocol  Routed 
Network,  see  Figure  1).  DMS  messages  will  be  transported  over  the  NIPRNET. 
Instead  of  encrypted  links,  which  now  dominate  the  AUTODIN  messaging 
architecture,  DMS  will  rely  on  a  variety  of  security  formats  whose  purpose  is  the 
security  and  encryption  of  the  message  itself,  vice  the  physical  link  over  which  it 
travels.  The  National  Security  Agency's  (NSA)  MISSI  (Multilevel  Information 
Systems  Security  Initiative)  program  is  responsible  for  DMS  message  security 
products  and  implementation.  A  primary  concern  is  the  loss  of  security  during 
message  processing  and  routing.  MISSI-encrypted  DMS  messages  (multimedia 
attachments  are  also  encrypted)  must  be  delivered  in  unaltered  form  to  the 
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reader.  MISSI  security  also  allows  for  authentication  of  message  sender  via  a 
digital  signature  which  is  electronically  "stamped"  on  the  message.  In  the 
context  of  this  thesis,  these  important  security  features  are  viewed  as  even  more 
bits  which  must  be  added  to  the  DMS  message  prior  to  transmission. 

4.  Proposed  solutions 

There  are  currently  two  proposals  for  resolving  the  limitations  of  applying 
DMS  over  broadcast  links.  The  first  method  (and  the  one  currently  being 
examined  for  Navy  tactical  DMS  implementation)  calls  for  translating  the 
X.400/DMS  message  back  to  an  AUTODIN  format  prior  to  transmission  over  all 
MILSATCOM  communication  systems,  both  duplex  and  broadcast.  The  key 
limitation  of  this  proposal  is  the  MILSATCOM  bandwidth  constraints  already 
discussed.  Furthermore,  this  proposal  violates  the  basic  DMS  elements  of 
service  for  the  tactical  users.  It  does,  however,  offer  a  near-term  solution  to  the 
protocol,  security  and  mobility  issues.  The  second  (longer-term)  proposal  calls 
for  a  direct  DMS  broadcast  capability  which  involves  an  alteration  of  the  P1 
protocol.  This  new  protocol,  the  Connectionless  Message  Transport  Protocol  or 
CMTP,  will  allow  the  X.400  application  to  operate  over  a  simplex  link.  However, 
it  does  not  address  the  lower-layer  routing  and  transport  concerns.  A  more 
detailed  review  of  these  proposals  and  their  limitations  is  undertaken  in  Chapter 
IV  of  this  thesis. 
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C.  THESIS  SCOPE 

Military  messaging  requirements,  met  in  the  past  by  service-specific 
systems,  will  now  be  incorporated  into  a  new  DoD-wide  email  environment. 

DISA  has  been  appointed  the  DMS  management  agent  and  as  such  is 
responsible  for  the  integration  and  interoperability  of  all  DMS  subsystems.  A 
decentralized  approach  to  subsystem  integration  and  compatibility  has  been 
chosen.  Each  service  has  been  tasked  only  to  find  solutions  to  its  particular 
messaging  needs,  with  all  proposed  DMS  architectures  containing  a 
standardized  interface  link  to  the  DISN.  The  interior  details  of  the  DISN  are  yet 
to  be  finalized  and  are  seen  as  beyond  the  scope  of  the  service  system 
developer's  requirements.  Key  to  the  effective  integration  of  this  distributed, 
systems  engineering  process  is  the  proper  implementation  of  accepted  interface 
protocols  and  formats  by  all  concerned. 

Tactical  DMS  implementations  must  deal  with  more  complex  connectivity 
hurdles  than  shore-based  systems,  as  outlined  in  the  previous  sections.  The 
interface  connection  from  the  tactical  user  to  the  common  DISN  cannot  be 
reduced  to  an  electronic  line  pointing  to  a  "cloud".  Realistic  answers  must  be 
outlined  and  management  issues  resolved. 

While  a  duplex  DMS  connectivity  to  tactical  units  is  certainly  essential,  this 
thesis  focuses  on  a  specific  technical  solution  to  the  broadcast  DMS  problem. 

An  architecture  and  concept  of  operations  for  a  high  data-rate,  DMS  capable 
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"next  generation"  Fleet  Broadcast  System  is  the  central  goal  of  this  thesis. 
Options  for  management  and  implementation  of  that  system  are  also  outlined. 
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II.  USN  FLEET  BROADCAST 


The  US  Navy's  broadcast  messaging  system  is  known  as  the  Fleet 
Broadcast  (FLTBCST).  The  current  FLTBCST  subsystem  is  an  automated, 
simplex  (shore-to-ship)  service  which  uses  low-rate  MILSATCOM  transponders 
to  broadcast  Top  Secret  and  below  General  Service  (GENSER)  message  traffic 
to  ships  and  other  mobile  units.  Messages  destined  for  broadcast  are 
automatically  prioritized,  formatted,  stored,  backlogged  and  routed  at  Naval 
Computer  and  Telecommunications  Area  Master  Stations  (NCTAMS)  by  the 
Navy  Communications  Processing  and  Routing  System  (NAVCOMPARS  or 
NCP).  NAVCOMPARS  is  based  on  early  1970's  mainframe  technology  and 
integrates  the  AUTODIN  with  the  operational  fleet  communication  subsystems. 

A.  NCTAMS  PROCESSING 

The  Navy  operates  four  NCTAMS:  Norfolk,  Virginia  (LANT);  Bagnoli,  Italy 
(MED);  Wahiawa,  Hawaii  (EASTPAC),  and  Finegayan,  Guam  (WESTPAC). 
These  stations  provide  satellite  and  HF  connectivity  to  fleet  users.  Theater 
Unified  Commanders  (CINCs)  maintain  operational  control  of  their  NCTAMS  and 
the  content  of  the  Fleet  Broadcast.  NCTAMS  currently  maintain  an  interface  to 
the  DISN  as  well  as  the  message-switched  AUTODIN  and  circuit-switched  voice 
subsystems.  The  HF  broadcast  capability  serves  as  a  back-up  method  of 
message  dissemination. 
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1.  Message  Processing 


Messages  received  by  the  NCP  are  first  recorded  in  their  original  format 
on  hard  disk  memory.  The  message  is  then  converted  to  a  common  format,  8  bit 
Extended  Binary  Coded  Decimal  Interchange  Code  (EBCDIC),  for  processing. 
The  NCP  system  analyzes  the  message  for  priority,  suspected  duplication, 
routing  indicator  and  distribution  assignment.  Transmission  scheduling  and 
queuing  are  also  automated,  with  each  message  processed  in  a  first-in,  first-out 
manner,  based  on  precedence  level.  Human  interface  and  control  is  provided 
via  a  command  line  terminal,  where  system  monitoring,  testing  and  manual 
message  injection  is  performed.  The  processed  message  is  again  recorded  on 
hard  disk  prior  to  transmission.  A  1985  Space  and  Naval  Warfare  Systems 
Command  report  found  that  an  average  of  12,000  broadcast  messages  are 
processed  by  each  NCTAMS  daily,  while  average  daily  broadcast  traffic  received 
by  a  major  combatant  ship  is  less  than  5000  messages  [Ref.  6]. 

2.  Message  Transmission 

The  Fleet  Broadcast  is  transmitted  to  tactical  users  via  three  frequency 
bands:  SHF/UHF  (satellite  links),  HF  and  VLF.  The  satellite  system,  controlled  at 
NCTAMS  sites,  uses  an  SHF  direct  sequence-spread  spectrum  uplink.  The 
signal  is  downconverted  by  the  satellite  to  the  UHF  band  and  then  downlinked  to 
small  omni-directional  antennas  onboard  ships.  The  broadcast  is  composed  of 
16  75bps  subchannels  which  are  time-division  multiplexed  (TDM)  into  a 
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composite  1200bps  data  stream:  eleven  general  service  (GENSER)  traffic 
channels,  two  weather  channels,  two  Special  Compartmented  Information  (SCI) 
level  Tactical  Intelligence  (TACINTEL)  channels  and  one  system  synchronization 
channel.  Once  received  onboard  ships,  the  UHF  downlink  is  demodulated  and 
demultiplexed:  GENSER  and  weather  subchannels  are  routed  to  the  ship's 
message  processor,  known  as  the  NAVMACS  (Naval  Automated 
Communications  System),  while  the  intelligence  traffic  is  forwarded  to  the  ship's 
TACINTEL  processors  and  teletypes. 


FLTBCST  messages  conform  to  a  variety  of  formats  including:  US 
Message  Text  Format  (USMTF),  Joint  Army,  Navy,  Air  Force  Publication 
standard  (JANAP)  128  ,  and  the  Allied  Communications  Policy  (ACP)  standard 
121/127.  Figure  2  depicts  a  simple  overview  of  a  ship's  current  FLTBCST 


communication  subsystem,  its  major  components  and  their  integration. 
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Figure  2.  Shipboard  Fleet  Broadcast  Subsystem.  After  Ref  [6]. 
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B.  NAVCOMPARS II 


The  Navy's  next  generation  shore-based  message  processing  system, 
NAVCOMPARS  II  (NCP  II),  incorporates  a  secure  software  operating 
environment  and  a  distributed  database  architecture  operating  on  a  Tactical 
Advanced  Computer-3  (TAC-3)  computer.  Under  the  NCP  II  architecture, 
NCTAMS  internal  subsystems  are  connected  by  an  Ethernet  (10Mbps)  network 
and  maintain  both  a  Government  Open  Systems  Interconnect  Profile  (GOSIP) 
and  a  more-widely  used  TCP/IP  external  connectivity.  NCP  M's  TAC-3  computer 
processes  messages  in  8-bit  ASCII  format.  Input  messages  are  converted  from 
their  particular  formats  (primarily  JANAP  128  and  ACP  127)  to  8-bit  ASCII, 
processed  with  much  the  same  functionality  as  the  original  NCP,  then  converted 
to  a  5-level  baudot  format  prior  to  transmission.  Conversion  of  outbound 
messages  from  ASCII  to  baudot  is  accomplished  by  a  gateway  known  as  the 
Distributed  Communications  Processor  (DCP). 

All  four  NCTAMS  will  be  linked  via  the  DISN  (specifically  the  NIPRNET). 
This  NCTAMS  Wide  Area  Network  (WAN)  will  provide  for  world-wide  Navy 
communications  integration  and  synchronization,  the  sharing  of  databases,  user 
location  data,  and  fast  secure  routing  of  message  traffic.  Messages  passed  on 
this  WAN  are  individually  encrypted  for  security  (except  for  header  data).  Initial 
installation  of  NCP  II  at  the  four  NCTAMS  sites  is  expected  by  1996.  NCP  II 
should  be  viewed  as  a  much  needed  software  and  hardware  upgrade  to  the 
current  Navy  communication  architecture,  not  as  a  change  in  that  architecture. 
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C.  FLEET  BROADCAST  SYSTEM  LIMITATIONS 


A  serious  drawback  to  the  continued  use  of  the  current  Navy  broadcast 
messaging  network  is  that  the  NCR  can  process  messages  faster  than  the 
FLTBCST  satellite  (and  HF)  subsystems  can  transmit  them.  To  account  for  the 
difference  in  input  and  output  rate,  NCR  uses  two  output  queues  commonly 
referred  to  as  Q1  and  Q2.  Q1 ,  with  a  total  capacity  of  6,200  messages,  serves 
as  an  accountability  queue  for  messages  while  awaiting  delivery  to  the 
transmission  subsystem.  Q2,  with  a  total  capacity  of  10,000  messages,  is  a 
buffer  memory  store  for  messages  queued  for  transmission  but  not  yet  confirmed 
as  transmitted.  The  primary  cause  of  communication  backlogs  (excessive  Q1 
queue  size)  within  the  NCR  are  the  slow  transmission  rates  of  the  satellite 
subsystems,  not  the  processing  capability  of  the  NCR  itself. 

NCR  II  will  greatly  increase  the  processing  speed  and  ease  the  operation 
and  maintenance  of  Navy  Fleet  Broadcast  management,  but  it  will  not  address 
the  bottlenecks  caused  by  current  transmission  interfaces.  Since,  as  presented 
in  Chapter  I,  average  message  size  can  be  expected  to  increase  under  the  DMS, 
a  central  limitation  of  current  Navy  broadcast  communication  networks  (under  an 
AUTODIN  or  DMS  paradigm)  remains  the  restricted  throughput  available  over 
military  satellite  systems.^ 

■  It  is  worth  noting  that  this  is  the  inverse  of  the  modern  commercial  telephone 
problem.  Commercial  phone  companies  needed  to  develop  faster  switching 
systems  (e.g.,  ATM  switches)  in  order  to  keep  up  with  the  increased  throughput 
offered  by  coaxial  cable  and  fiber  optics  [Ref.  8] 
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Within  the  DMS  framework,  these  physical  limitations  are  compounded  by 
the  fact  that  X.400  connectivity  was  not  viewed  as  a  critical  initial  requirement  of 
the  NCP  II;  therefore  NCP  II  will  be  fielded  with  no  direct  capability  to  accept  and 
process  DMS  traffic.  Effective  application  of  gateways  and  interfaces  to  the 
current  NCP  and  future  NCP  II,  in  order  to  adapt  a  DMS  capability,  poses  a  new 
set  of  interoperability,  cost  and  management  issues  for  near-term  tactical  DMS 
implementation. 
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III.  GLOBAL  BROADCAST  SERVICE  (GBS) 


A.  INTRODUCTION 

Satellite  reception  equipment  has  been  publicly  available  since  1976  when  the 
first  home  satellite  TV  system  was  put  into  service  in  California  [Ref.  9].  These  early 
systems  used  8-12  foot  antennas  to  capture  (often  illegally)  analog  C-band  TV 
broadcasts  from  national  and  local  TV  companies.  At  $2000-$4000  these  TV  "earth 
terminals"  were  not  cheap.  Furthermore,  by  1990  most  C-band  TV  signals  were 
encrypted,  forcing  satellite  TV  owners  to  pay  for  decryption  equipment. 

In  1982,  the  FCC  (Federal  Communications  Commission)  and  the  ITU 
(International  Telecommunications  Union)  allocated  the  12.2-12.7  GHz  band  for 
direct-to-home  satellite  broadcast  use.  Then  in  1984,  United  Satellite  Communication 
Inc.  (USCI)  implemented  the  first  commercial  direct  broadcast  service  (DBS)  to  US 
consumers.  This  venture  offered  satellite  TV  reception  from  a  dedicated  provider  whose 
signal  was  broadcast  by  a  leased  Canadian  satellite  transponder.  However,  USCI 
failed  to  attract  more  than  7000  customers  and  went  bankrupt  in  1985  [Ref.  9]. 

In  the  time  since  those  early  attempts,  advances  in  several  commercial 
technologies  have  made  high  data-rate,  digital  data  broadcast  into  small,  inexpensive 
receive  antennas  a  reality.  Furthermore,  this  new  technology  is  directly  applicable  to 
the  US  military's  modern  communication  needs.  This  chapter  will  review  the 
development  of  this  new  data  broadcast  technology,  its  military  application  and  current 
military  initiatives  within  this  field. 


25 


B.  HISTORY  AND  CONCEPT  DEVELOPMENT 


1 .  Direct  Broadcast  Service  (DBS) 

In  1994,  DirecTV  (a  Hughes  subsidiary)  and  United  States  Satellite  Broadcasting 
(USSB)  joined  forces  to  provide  a  direct  broadcast  service  (DBS)  to  the  continental  US. 
This  satellite-based  multimedia  service  combines  high  bandwidth  links  and  large  area 
coverage.  There  are  three  key  components  to  the  initial  success  of  this  new 
commercial  technology: 

•  large  selection  of  high-quality  full  digital  audio  and  video  channels  (up  to  200) 

•  small  receive  antenna  (18")  coupled  to  a  small  receiver/decoder 

•  low  cost  of  equipment  (under  $700). 

The  DirecTV/USSB  transmission  subsystem  incorporates  three  geosynchronous 
satellites  and  two  ground  uplink  sites.  Input  digital  video  and  audio  signals  are  first 
passed  through  MPEG  (Motion  Pictures  Expert  Group  -  an  International  Standards 
Organization  entity)  compression  algorithms.  Reed-Solomon  forward  error  correction 
and  security  encoding  is  applied  to  the  digital  datastream  prior  to  QPSK  (Quadrature 
Phase  Shift  Keying)  uplink  modulation  at  17.3-17.8  GHz.  The  satellite  then 
downconverts  the  signal  to  the  FCC  approved  frequencies  (12.2-12.7  GHz)  prior  to 
broadcast.  Once  captured  by  the  small  receive  antenna,  the  signal  is  demodulated  and 
decoded  by  the  home  receiver  and  the  selected  channel  is  routed  to  the  user's  TV. 
Compression  algorithms,  FEC  and  satellite  transponder  saturation  provide  system  data 
throughput  of  23Mbps  with  a  bit  error  rate  (BER)  of  10'^°.  Figure  3  depicts  a  block 
diagram  of  the  DirecTV/USSB  commercial  DBS  system. 
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Figure  3.  Commercial  DBS  System  Block  Diagram.  After  Ref  [9]. 


2.  Global  Broadcast  Service  (GBS) 

The  military  application  of  this  new  high  data-rate,  small  receive  antenna 
technology  is  known  as  GBS  (Global  Broadcast  Service).  In  May  of  1995,  the  US  Joint 
Chiefs  of  Staff  issued  a  Joint  Mission  Need  Statement  (MNS)  which  delineated  the 
basic  operational  requirements  of  the  GBS  concept.  In  summary,  the  statement  called 
for  [Ref.  10]: 

•  a  DBS-based  system  to  provide  secure  simultaneous  broadcast  of  multimedia 
information  (video,  data,  imagery)  to  all  approved  recipients  in  a  theater  of 
operations 

•  world-wide  coverage  from  70°  N  to  70°  S 

•  use  of  commercial  off-the-shelf  technologies  and  low  risk,  non-developmental 
equipment 
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•  integration  of  the  GBS  system  to  the  DISN 

•  security  for  data  transmission  at  all  classification  levels  from  UNCLAS  to  SCI. 

The  GBS  Joint  MNS  was  followed  by  a  draft  GBS  Concept  Of  Operations 
(ConOps),  prepared  by  the  US  Space  Command  in  August  1995.  The  GBS  ConOps 
details  preliminary  implementation  concepts  and  information  management  options,  but 
does  not  address  any  system-specific  parameters  or  architectures.  The  following  points 

are  presented  in  the  GBS  ConOps  [Ref.  11]: 

•  primary  interface  for  GBS  service  requests  will  be  the  GCCS  (Global  Command 
&  Control  System). 

•  GBS  will  augment  current  MILSATCOM  systems,  relieving  them  of  much  of  the 
one  way  data  traffic  they  now  carry. 

•  GBS  will  incorporate  a  warfighter-responsive  broadcast  management  structure 
which  transmits  data  from  CONUS  uplink  sites  while  also  allowing  in-theater 
(CINC-responsive)  direct  injection  of  data. 

•  two  modes  of  operation  are  called  for:  wide  area  coverage  and  steerable  "spot 
beams". 

•  GBS  will  provide  three  classes  of  tailored  service:  on-demand,  continuous  and 
periodic. 

•  the  GBS  system  will  maintain  interoperability  with  IP-based  addressing 
schemes  already  in  use  by  DoD. 

C.  INITIAL  GBS  DESIGN 

In  November  1995,  the  Joint  Staff  validated  the  need  for  GBS,  allocated 
approximately  $900M  in  funding  and  directed  the  Under  Secretary  of  Defense 
(Acquisition  and  Technology)  to  establish  a  Joint  Program  Office  to  manage  the 
program  [Ref.  12].  The  US  Air  Force  was  named  lead  agency/service  for  program 
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development,  while  the  Army  will  formulate  the  GBS  Operational  Requirements 
Document  (ORD). 

There  is  no  single,  approved  system  architecture  for  GBS.  However,  initial  GBS 
design  concepts  closely  follow  the  commercial-based  DBS.  Figure  4  illustrates  a  typical 
GBS  system  structure  and  data  flow.  Major  differences  between  GBS  and  commercial 
DBS  include  the  use  of  ATM  (asynchronous  transfer  mode),  a  switching  technology 
used  here  in  a  transport/transmission  role,  and  the  use  of  bulk  encryption  for  obvious 
security  reasons^  The  GBS  space  segment  and  ground-based  information 
flow/mangement  concepts  are  detailed  in  the  following  subsections. 

1 .  GBS  Space  Segment 

There  were,  initially,  two  options  for  implementing  the  GBS  space  segment 
(satellites  and  transponders):  leased  commercial  systems  and  military-only  systems. 
While  LORAL  Corporation  (a  Lockheed-Martin  Company)  and  Hughes  have 
DBS-capable  satellites  in  orbit,  none  of  the  current  MILSATCOM  communication 
systems  is  optimized  for  GBS  service  [Ref.  9].  In  December  1995,  the  Joint  Staff, 
based  on  recommendations  by  the  Space  and  Naval  Warfare  Systems  Command 
(SPAWAR),  approved  plans  to  place  GBS  transponders  aboard  the  US  Navy's  Ultra 


The  BER  is  significantly  improved  by  means  of  double  (concatenated)  FEC 
encoding  applied  to  the  uplink  signal  in  the  form  of  Reed-Solomon  (R-S)  block  encoding 
and  convolutional  encoding.  Viterbi  decoding  is  performed  prior  to  decryption  in  order 
to  reduce  the  error  rate  to  a  point  where  decryption  can  be  done  reliably.  R-S  decoding 
must  be  applied  after  decryption;  otherwise  the  error-extension  properties  of  the 
decryptor  significantly  degrade  the  improvement  obtainable  from  R-S  FEC.  [Ref.  9]. 
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Figure  4.  GBS  System  Block  Diagram.  After  Ref  [9]. 


High  Frequency  Follow-On  (UFO)  satellites.  Proposals  call  for  the  SHF  Fleet  Broadcast 
transponders  aboard  UFO  #8,  #9  and  #10  to  be  replaced  with  four  GBS  (EHF  band) 
transponders,  a  modified  power  subsystem  and  improved  heat  dissipation  structures 
prior  to  launch  [Ref.  1 1].  There  are  currently  five  UFO  satellites  in  orbit  with  four  others 

scheduled  for  launch.  These  modifications  will  give  each  UFO  satellite: 

•  two  steerable  GBS  spot-beams  (500  nautical  mile  diameter  coverage  each) 
operating  at  24Mbps 

•  one  wide  area  (2000  nm)  low-rate  GBS  broadcast  operating  at  1 .544  Mbps 

•  uplink  accessibility  from  at  least  one  (of  four)  NCTAMS  site  at  all  times. 

Initial  GBS/UFO  operational  capability  is  slated  for  the  first  quarter  of  1998,  with  full 
system  implementation  within  one  year.  The  three  modified  UFO  satellites  will  satisfy 
all  space  segment  requirements  set  forth  by  the  1995  GBS  Joint  Mission  Need 
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statement.  Table  2  summarizes  the  expected  performance  levels  of  the  three  GBS 
capable  UFOs. 


PARAMETERS 

pERSPACECWT  i 

GtOEAt 

Number  of  ^ot  Stearns 

2 

6 

transponders 

4 

12 

Tt3|al  Data  Rate  pt^s) 

96 

288 

Trah^onder  Redundancy 

5  for  4 

Dowr#ifeeRF  (dSftAO . 

54.5 

Spot  Beam  Antenna  Size  (in.)  i 

22 

Total  TWT  pdwerfWatts) 

120  (47%  eff) 

Receive  Antemna  Sfee  (In.) 

18 

Uplink  Frequenc^.(£HF) 

30-31  GHz 

D<»wntink  Frequency  (SHF) 

20.2-21.2  GHz 

Table  2.  GBS-Capable  UFO  Performance  Summary.  After  Ref  [13]. 


2.  Broadcast  Management  Centers 

While  technical  parameters  and  required  modifications  have  been  outlined  for 
the  GBS  space  segment,  there  is  as  yet  no  approved  plan  for  the  development  of  the 
information  management  infrastructure  or  coordination  guidelines  for  the  various  data 
inputs  and  subsequent  requests  for  service.  However,  there  exists  within  the  GBS 
development  community  a  widely-accepted  concept  of  a  Broadcast  Management 
Center  (BMC)  which  must  be  capable  of: 

•  integrating  and  processing  ATM,  non-ATM,  video,  imagery  and  weather  data 

•  accepting  and  processing  requests  for  GBS  services  from  users  over 
MILSATCOM  and  land-based  networks 

•  maintaining  data  security  up  to  the  SCI  level 

•  communicating  with  other  BMCs  in  order  to  coordinate  the  GBS  world-wide. 
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The  GBS  concept  denotes  both  a  CONUS-based  BMC/uplink  facility  and  theater 
CINC-controlled  BMCs.  However,  the  physical  location  of  the  broadcast  sites,  both 
CONUS  and  theater,  has  not  been  finalized.  The  JCS  decision  to  modify  Navy  UFO 
satellites  for  a  GBS  role  all  but  mandates  the  use  of  NCTAMS  as  GBS  uplink  sites. 
However,  these  NCTAMS,  especially  the  new  NAVCOMPARS  II  equipped  sites,  can 
also  offer  excellent  GBS  information  fusion,  management,  coordination  and  data 
exchange  capabilities  as  well. 

NCTAMS,  as  previously  noted,  are  CINC  controlled  communication  centers 
which  already  gather,  fuse,  process  and  disseminate  military  data  up  to  the  SCI  level. 
The  information  infrastructure  and  physical  data  links  from  the  DISN  to  the  warfighter 
via  the  NCTAMS  communication  hub  are  already  in  place.  World-wide  coordination  of 
the  GBS  broadcast  can  be  maintained  via  the  DISN-based  NCTAMS  WAN. 
Furthermore,  the  open  systems  architecture  of  the  NAVCOMPARS  II  TAC-3  computer 
system  allows  for  easy  integration  of  both  ATM,  non-ATM,  video  and  audio 
datastreams.  Requests  for  GBS  services  can  be  quickly  processed,  since  NCTAMS 
currently  operate  the  duplex  systems  marked  for  use  as  the  warfighter's  primary  GBS 
service  request  channels.  The  NCTAMS  currently  operate  within  the  same 
communication  paradigm  envisioned  by  the  GBS  concept,  namely  the  direct 
dissemination  of  information  and  data  to  the  warfighter.  They  represent  the  best 
method  of  integrating  GBS  services  at  the  warfighter  level  without  adding  new 
information  management  layers  to  the  theater  CINCs.  Figure  5  outlines  how  the 
internal  data  flow  of  a  NCTAMS,  acting  as  a  GBS  theater  BMC,  can  be  structured. 
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While  NCTAMS  may  be  well-suited  as  GBS  theater  BMCs,  there  remains  a  need 
as  noted  by  both  the  GBS  ConOps  and  MNS  for  a  CONUS-based  coordination  and 
uplink  facility.  This  site  will  have  access  to  both  the  Atlantic  and  Pacific  GBS  satellites, 
while  maintaining  a  centralized  management  capability  for  GBS  services  and  requests 
world-wide.  It  would  also  serve  as  a  primary  JCS/National  Command  Authority  data 
injection  site.  Current  proposals  indicate  that  this  site  may  be  managed  by  either  DISA 
or  USSPACECOM. 


D.  CONCLUSIONS 

High  data-rate  direct  broadcast  services,  recently  perfected  by  civilian  industry, 
represent  a  unique  and  timely  opportunity  for  the  US  military  to  vastly  improve  its  data 
dissemination  architecture  without  extended  research  and  development  of  proprietary 
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systems.  It  is  not  a  stretch  to  note  that  the  US  military's  operational  requirements  for 
high  throughput  broadcast  services  have  been  outpaced  by  the  commercially-led  DBS 
technology  explosion.  Yet,  preliminary  integration  of  GBS  signal  processors  and 
stabilized  antennas  onto  mobile  platforms  (e.g.,  ships)  has  been  accomplished. 
Fourteen  US  warships  are  currently  outfitted  with  commercial  DBS  systems,  and  GBS 
systems  have  been  installed  on  several  tactical  platforms,  including  aircraft  [Ref.  14]. 
Theater-level  GBS  systems  are  operational  in  Europe  (in  support  of  NATO  Forces  in 
the  former  Yugoslavia),  and  in  the  continental  US  fortesting  and  concept  evaluation. 

The  GBS  space  segment  architecture  has,  for  the  near  future,  been  defined  and 
set  in  motion.  However,  the  current  state  of  GBS  information  management,  including 
data  injection,  requests  for  service  and  data  format  standardization,  is  seriously  lagging 
behind  its  technical  capabilities.  CINC-controlled  broadcasts,  theater-direct  data 
injection,  and  the  effective  integration  of  GBS  with  the  DISN  should  compose  the 
central  focus  of  near-term  GBS  system  development. 

Use  of  the  NCTAMS  as  a  theater  focal  point  for  GBS  broadcast  coordination 
allows  a  relatively  simple  migration  of  the  legacy  Fleet  Broadcast  subsystem  to  a  new, 
robust,  high-speed  data  link.  Weather,  intelligence  and  GENSER  message  traffic, 
currently  transmitted  at  75bps  can  now  be  integrated  onto  a  GBS  (23Mbps)  datastream 
for  broadcast  to  the  fleet  and  other  tactical  users.  The  details  of  this  proposed 
integration  and  how  it  can  extend  a  DMS  broadcast  to  tactical  mobile  units  is  the  focus 
of  the  next  chapter. 
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IV.  DMS  BROADCAST  OVER  GBS 


A.  INTRODUCTION 

Current  Navy  proposals  omit  any  near-term  DMS  broadcast  capability. 
Instead,  Navy  tactical  DMS  plans  call  for  the  conversion  of  X.400  messages  to 
the  legacy  AUTODIN  formats  via  a  Multi-Function  Interpreter  (MFI).  The  MFI  will 
"translate"  messages  back  and  forth  between  X.400  and  AUTODIN  formats. 
Converted  messages  are  then  transmitted  over  the  MILSATCOM 
duplex/broadcast  systems  to  tactical  units.  This  is  a  short  term  solution.  With 
AUTODIN  replacement  mandated  by  2000  [Ref.  2],  a  more  flexible,  integrated 
tactical  DMS  solution  needs  to  be  articulated.  Furthermore,  a  DMS  broadcast 
capability  needs  to  be  developed  to  replace  the  existing  Fleet  Broadcast  system. 

As  outlined  in  Chapter  I,  DoD  development  of  a  new  protocol  (CMTP)  will 
allow  data  transmission  from  an  originating  MTA  to  a  recipient  MTA  without  the 
need  for  application-layer  connectivity  and  acknowledgment  of  message 
delivery.  This  alteration,  however,  is  directed  at  the  higher  (application)  layer 
and  does  not  address  the  general  restrictions  of  TCP/IP  over  a  connectionless 
link.  The  NIPRNET  (on  which  DMS  messages  are  carried)  cannot  be  extended 
over  a  broadcast  network,  chiefly  because  TCP  can  only  operate  over  a 
interactive  (duplex)  link. 

In  response  to  this  limitation,  it  is  expected  that  after  development  of 
CMTP,  broadcast  DMS  will  incorporate  an  unreliable,  broadcast-capable 
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transport  protocol  known  as  UDP  (User  Datagram  Protocol)  [Ref.  1 5].  This 
simplex-capable  protocol  enables  the  transport  of  datagrams  without  sequencing 
information,  error  correction  or  the  capability  for  retransmission  of  lost  packets.  It 
allows  a  sending  node  to  transmit  datagrams  without  responses 
(acknowledgments)  from  the  receiving  node.  However,  use  of  UDP  is  traded  off 
against  possible  datagram  non-delivery,  error  correction  and/or  duplication.  UDP 
is  an  unreliable  method  for  transporting  operational  message  traffic. 

The  DMS  Tactical  Working  Group  reports  that  preliminary  broadcast  DMS 
testing  can  be  expected  after  1999  [Ref.  16].  Meanwhile,  tactical  units  will 
receive  messages  of  greater  size  (due  to  X.400/AUTODIN  conversion  overhead, 
MISSI  and  multimedia  enclosures)  over  current  MILSATCOM  systems  at 
75-9600  bps. 

This  chapter  presents  a  viable  solution  for  DMS  extension  to  the  tactical 
environment  and  a  conceptual  outline  for  a  robust  broadcast  network  to  replace 
the  current  Fleet  Broadcast  system.  The  concept  integrates  relatively  new  IP 
routing  schemes  with  the  GBS  broadcast  system  presented  in  the  previous 
chapter.  The  application  of  GBS  as  a  "next  generation"  Fleet  Broadcast  offers 
an  expansive  leap  in  tactical  broadcast  communication  capability.  The  proposed 
communications  architecture  is  a  high  data-rate  broadcast  system,  capable  of 
carrying  DMS  traffic  to  tactical  units.  Some  assumptions  are  made  within  the 

scope  of  the  concept  as  presented;  they  are: 

•  NCTAMS  are  outfitted  with  GBS  subsystems  and  routers  capable  of 
forwarding  DMS  data  packets  to  them 
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•  The  DISN  is  fully  operational  and  ties  together  all  terrestrial  DoD 
communication  nodes 

•  The  four  NCTAMS  are  linked  via  the  DISN,  as  outlined  in  Chapter  I 

•  GBS  is  implemented  with  (as  required)  world-wide  coverage. 

B.  ENABLING  TECHNOLOGIES 

The  most  critical  aspect  of  this  tactical  DMS  broadcast  concept  is  the 
effective  routing  of  messages  to  mobile  units  which  are  not  continuously 
connected  to  the  same  network  (DISN)  interface.  IP  version  6  (IPv6)  and  mobile 
IP,  both  recently  developed  commercial  protocol  standards,  address  this 
requirement.  Their  use  can  effect  a  general,  scaleable  and  easily  implemented 
solution  to  the  problem  of  broadcasting  DMS  messages  to  mobile,  tactical  units. 

1 .  IPv6  and  Anycast  Addressing 

IPv6,  formalized  by  an  Internet  Engineering  Steering  Group  in  November 
1994,  was  developed  as  an  evolutionary  improvement  over  the  current  Internet 
Protocol  (IP  version  4)  [Ref.  17].  It  can  be  installed  as  a  software  upgrade  in 
Internet  devices  (routers,  switches,  gateways,  bridges,  etc.)  and  can  coexist  with 
systems  using  the  current  IPv4.  Furthermore,  IPv6  is  designed  to  run  well  on 
high  performance  networks  (e.g.,  ATM  switched  networks)  while  at  the  same 
time  is  still  efficient  for  low  bandwidth  networks  (e.g.,  MILSATCOM).  Key 

upgrades  from  IPv4  to  IPv6  include  [Ref.  17]: 

•  expanded  routing  and  addressing  capabilities.  IPv6  increases  the  IP 
address  size  from  32  bits  to  128  bits,  which  supports  more  levels  of 
addressing  hierarchy,  a  much  greater  number  of  addressable  nodes,  and 
simpler  auto-configuration  of  addresses. 
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•  header  format  simplification.  Some  IPv4  header  fields  have  been 
dropped  or  made  optional,  to  reduce  the  processing  cost  of  packet 
handling  and  to  keep  the  bandwidth  cost  of  the  IPv6  header  as  low  as 
possible  despite  the  increased  size  of  the  addresses.  Even  though  IPv6 
addresses  are  four  times  longer  than  the  IPv4  addresses,  the  IPv6  header 
is  only  twice  the  size  of  the  IPv4  header. 

•  improved  support  for  options.  Changes  in  the  way  IP  header  options 
are  encoded  allows  for  more  efficient  forwarding,  less  stringent  limits  on 
the  length  of  options,  and  greater  flexibility  for  introducing  new  options  in 
the  future. 

•  quality-of-service  capabilities.  A  new  capability  is  added  to  enable  the 
labeling  of  packets  belonging  to  particular  traffic  "flows"  for  which  the 
originator  requests  special  handling,  such  as  acknowledgments  or 
"real-time"  service. 

•  authentication  and  privacy  capabilities.  This  includes  the  definition  of 
extensions  which  provide  support  for  authentication,  data  integrity,  and 
confidentiality. 

•  multiple  addressing  schemes.  Besides  the  standard  unicast  address, 
IPv6  incorporates  multicast  addressing  and  anycast  addressing. 


IPv6  represents  a  cost-effective,  non-developmental,  backward- 
compatible  upgrade  to  the  current  IP  protocol.  It  should  be  adopted  for  DISN 
implementation,  even  if  just  for  its  128  bit  address  size  and  the  ability  to  multicast 
data  packets.  Of  primary  importance  to  this  thesis,  however,  is  the  development 
of  a  new  addressing  scheme  within  IPv6  known  as  the  anycast  address. 

An  anycast  address  is  an  IP  address  assigned  to  more  than  one  network 
interface  (e.g.,  router).  Its  primary  property  is  that  a  datagram  sent  to  an  anycast 
IP  address  is  routed  to  the  "nearest"  interface  advertising  that  address. 
"Nearness"  is  based  on  the  routing  protocol’s  measure  of  distance,  vice  physical 
distance,  and  takes  traffic  load  and  throughput  speed  into  consideration 
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[Ref.  17].  In  essence,  anycast  addresses  are  created  when  a  node's  unicast 
address  (unique  IP)  is  assigned  to  more  than  one  network  interface. 

This  new  addressing  scheme  allows  several  network  interfaces  to  receive 
and  accept  datagrams  for  a  single  node.  In  this  manner  a  node  can  move  from 
one  network  interface  to  another,  share  anycast  addresses  between  itself,  its 
new  host  and  any  other  interface,  and  be  assured  that  datagrams  will  be  routed 
to  it  regardless  of  which  interface  actually  receives  them.  Furthermore,  a  node 
can  use  its  "home  network"  IP  address  as  an  anycast  IP  address,  therefore 
negating  the  need  to  update  or  change  its  IP  addresses  every  time  it  moves  to  a 
new  network  interface.  A  graphical  representation  of  the  anycast  IP  address 
concept  is  depicted  in  Figure  6. 


Figure  6.  Anycast  IP  Address  Scheme 


In  order  to  effect  a  seamless  transfer  of  datagrams  from  all  anycast 
interfaces  to  the  intended  recipient  node,  another  routing  scheme  must  be 


incorporated.  Specifically,  the  details  of  how  datagrams  are  passed  from  an 
accepting  anycast  interface  to  a  mobile  recipient  node,  not  physically  connected 
to  that  interface,  are  outlined  below. 

2.  Mobile  IP 

Documented  in  February  of  1996  by  the  Mobile  IP  Working  Group  of  the 
Internet  Engineering  Task  Force,  mobile  IP  allows  automatic  routing  of 
datagrams  to  mobile  nodes  regardless  of  their  geographic  location  or  use  of 
different  network  interfaces  [Ref.  17].  The  concepts  behind  mobiie  IP  are  not 
tied  to  the  use  of  either  IPv4  or  IPv6:  they  can  be  implemented  on  a  network 
which  uses  either  (or  both)  protocols. 

Current  IP  routing  schemes  assign  a  unique  IP  address  to  a  network 
node.  This  IP  distinguishes  it  from  all  other  nodes  on  that  network.  If  the  node 
becomes  mobile  and  cannot  directly  connect  to  its  home  network,  it  must  change 
its  IP  address  in  order  to  receive  datagrams  while  connected  to  the  new  network. 
This  method  can  often  cause  loss  of  connectivity  until  the  node's  new  IP  address 
has  been  registered  throughout  the  network's  routing  tables.  Mobile  IP  offers  a 
mechanism  through  which  mobile  nodes  can  connect  to  any  network  interface 
and  still  receive  their  data. 

A  mobile  node  is  always  associated  with  the  IP  address  of  its  home 
interface,  known  as  a  home  agent,  even  when  physically  away  from  its  home. 
When  away  from  home,  the  node  is  also  associated  with  whatever  interface  it 
uses  to  reconnect  to  the  network.  The  "away"  interface,  known  as  a  foreign 
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agent,  is  registered  with  the  home  agent  whenever  the  mobile  node  changes 
network  interfaces.  The  home  agent  then  reroutes  all  datagrams  intended  for 
the  mobile  node  to  that  unit's  foreign  agent  for  delivery.  The  home  agent  "wraps" 
the  datagrams  in  another  IP  datagram  whose  address  header  contains  the  IP 
address  of  the  foreign  agent.  This  process  is  known  as  "tunneling".  The  foreign 
agent  "unwraps"  the  tunneled  datagram,  reads  the  IP  address  of  the  contained 
datagram  and  delivers  it  to  the  intended  mobile  node.  In  this  manner  the  home 
agent  maintains  a  virtual  connection  with  the  mobile  node  through  the  foreign 
agent  which  maintains  a  physical  connection.  Datagrams  sent  by  the  mobile 
node  are  delivered  to  their  intended  recipient  using  standard  IP  routing:  they  are 
not  routed  through  a  home  agent.  Figure  7  depicts  a  simple  overview  of  the 
mobile  IP  concept. 

2.  the  home  agent  re-routes  the  datagrams  to  the  mobile  node's  I 

foreign  agent  via  a  mobile  IP  "tunnel"  I 


1 .  the  originating  host  does  not  know  (nor  should  it  care)  that  the  mobile 
node  is  not  at  its  home  network.  It  sends  all  datagrams  to  the 
home  IP  address  of  the  mobile  node. 


Figure  7.  Mobile  IP  Routing  Concept.  After  Ref  [17], 
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C.  GETTING  A  DIMS  MESSAGE  TO  A  TACTICAL  UNIT 


In  order  to  organize  the  DMS  broadcast  over  GBS  concept  in  a  manner 
related  to  the  operational  aspects  of  tactical  units,  it  is  presented  based  on  the 
following  scenario:  Two  ships,  homeported  at  Naval  Station  Mayport,  Florida  are 
preparing  to  get  undenway.  USS  SPRUANCE  (DD-963)  is  scheduled  for  a  six 
month  Mediterranean  deployment.  USS  GETTYSBURG  (CG-64)  is  preparing  for 
a  two  week  exercise  off  the  eastern  US  coast.  SPRUANCE  has  Commander 
Destroyer  Squadron  2  (COMDESRON  2)  embarked.  At  the  same  time  two  other 
naval  vessels,  USS  HOUSTON  (SSN-713)  and  USNS  ALTAIR  (T-AKR  291),  a 
civilian-manned  rapid  response  cargo  ship,  are  currently  on  station  in  the  Pacific. 
The  scenario  will  incorporate  the  flow  of  DMS  messages  as  they  are  routed  over 
the  DISN  (NIPRNET)  and  GBS  to  finally  arrive  at  the  correct  unit.  Details  on  the 
accomplishment  of  specific  messaging  processes  are  delineated  as  they  occur. 

1.  UnitPierside 

In  this  case  the  tactical  unit  is  no  more  than  a  building  afloat  on  the  water. 
DISN  connectivity,  and  therefore  DMS  connectivity,  are  obtained  via  the  port's 
Naval  Communications  Station  (NAVCOMSTA)  acting  as  home  agent.  Tactical 
units  access  the  NAVCOMSTA's  DISN  routers  via  a  dedicated,  dial-up  access 
phone  line.^  Eventual  rewiring  of  homeports  with  coaxial  cable,  fiber  optic  or 

^  A  very  viable  alternative  is  the  continued  reception  of  DMS  traffic  over  the 
GBS  system  even  while  moored  inport.  This  is,  however,  a  doctrinal  vice 
technical  question  and  is  not  examined  in  this  thesis. 


42 


even  wireless  (line-of-sight)  extensions  to  pierside  units  would  certainly  be  a 
welcomed  improvement,  but  they  do  not  alter  the  basic  premise  of  tactical  unit 
connectivity:  tactical  units  are  mobile  and  therefore  must  be  able  to  disconnect 
from  the  pierside  connections  and  not  lose  communication  connectivity. 

2.  Unit  Underway 

Once  underway,  the  direct  DISN  (and  therefore  DMS)  interface  for  each 
tactical  unit  will  be  a  NCTAMS.  Twenty-four  hours  prior^  to  getting  underway 
from  homeport,  communication  personnel  aboard  the  tactical  units  inform  their 
respective  homeport's  NAVCOMSTA  of  their  expected  departure.  This  process  is 
known  as  a  communication  guard  shift  or  "corn-shift".  The  IP  routing  tables 
within  the  NAVCOMSTA's  DISN  router  and  DMS  MTA  are  updated  to  indicate 
that  these  subscribers  are  out  of  homeport.  Each  tactical  unit's  corn-shift 
message  really  establishes  an  anycast  address  scheme  between  its 
NAVCOMSTA,  the  NCTAMS  under  whose  control  it  falls,  and  itself.  The 
NAVCOMSTA’s  routers  are  also  updated  to  automatically  reroute  all  message 
traffic  intended  for  the  underway  unit  back  over  the  DISN  to  a  NCTAMS  using  a 
mobile  IP  tunnel  (home  agent  to  foreign  agent  routing). 

Concurrently,  tactical  units  also  report  changes  in  their  operational  status 
to  the  NCTAMS  nearest  their  homeport  (or  port  of  departure).  The  NCTAMS' 
DISN  router  is  reconfigured  by  operators  as  a  foreign  agent,  based  on  the 

^  Based  on  current  USN  policies.  Efficient  use  of  network  technologies  can 
considerably  reduce  the  time  lag  involved  in  shifting  communications  guard. 
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tactical  unit's  requests,  which  accepts  receipt  of  DMS  messages  addressed  to 
the  tactical  unit.  The  NCTAMS  MTA,  which  maintains  a  duplex  DISN 
connectivity,  accepts,  error-corrects  and  reassembles  all  DMS  datagrams.  The 
in-sequence,  error-free  DMS  message  datagrams  are  then  routed  to  the  GBS 
subsystem  (ATM  multiplexer)  for  broadcast  queuing.  The  NCTAMS  MTA  also 
returns  a  modified  acknowledgment  of  receipt  to  the  originator.  The  modified 
acknowledgment  should,  at  the  minimum,  state  that  the  message  has  been 
received  by  the  NCTAMS  for  GBS  queuing  and  indicate  receipt  date  and  time. 
This  informs  the  message  originator  not  to  expect  immediate  receipt  or  read 
acknowledgments  from  the  intended  recipient,  as  DMS  standards  mandate.  The 
NCTAMS'  messaging  system  can  also  relay  acknowledgment  of  GBS  message 
transmission  (or  when  it  will  be  transmitted)  back  to  the  originator.  In  essence, 
the  NCTAMS  acts  as  the  connectivity  point  for  broadcast  messages  addressed 
to  all  underway  tactical  units  within  its  area  of  responsibility.®  Figure  8  is  a  simple 
overview  of  the  proposed  routing  scheme  and  how  it  incorporates  the  anycast 
and  mobile  IP  concepts. 

For  the  proposed  scenario,  the  "corn-shift"  message  initiated  by 
GETTYSBURG  prior  to  getting  undenway  informs  NAVCOMSTA  Mayport  (home 
agent)  to  route  all  traffic  to  NCTAMS  l_ANT  (foreign  agent).  NCTAMS  LANT, 
also  informed  of  GETTYSBURG'S  underway  status,  accepts  responsibility  as 

®  This  could  occur  in  much  the  same  manner  that  it  does  now.  It  is  expected 
that  extension  of  duplex  DMS  connectivity  to  tactical  units  will  also  occur  via  the 
current  NCTAMS  sites. 
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GETTYSBURG'S  foreign  agent,  returns  DMS  message  acknowledgments  and 
reroutes  message  datastreams  to  the  GBS  subsystem  for  transmission.  DMS 
traffic  sent  to  GETTYSBURG'S  IP  address  (now  shared  amongst  itself, 
NAVCOMSTA  Mayport  and  NCTAMS  LANT  as  an  anycast  address)  will  either 
be  routed  to  NAVCOMSTA  Mayport,  who  then  tunnels  them  to  NCTAMS  LANT, 
or  directly  to  NCTAMS  LANT  for  broadcast. 


DISN 


GBS 


NCTAMS 


DISN 


NAVCOMSTA  /  ,  0< _ ^ 

/  \ 

1 

< 

1 

1 

tactical  unit  (at  sea) 

mobile  IP  tunnel  (over  the  DISN) 

{  / 

NAVCOMSTA  and  NCTAMS  share  anycast  IP  with  tactical  unit.  ' 

Datagrams  addressed  to  unit  can  be  accepted  by  either.  If  NAVCOMSTA 
receives  them,  it  will  tunnel  them  to  NCTAMS  for  broadcast. 


Figure  8.  Proposed  Mobile  IP/Anycast  Routing  Scheme. 


The  use  of  anycast  addresses  ensures  that  all  DMS  traffic  is  received  either 
at  the  NAVCOMSTA  or  the  NCTAMS,  depending  on  which  is  the  nearest 
interface.  Remember  that  the  current  IPv4  ties  a  node  to  the  network  from  which 
it  received  its  IP  address.  This  means  that  the  tactical  unit  (while  in  homeport)  is 
seen  as  a  node  of  the  NAVCOMSTA's  DISN  subnet,  and  that  subnet  will  be 
advertised  as  the  physical  location  of  the  unit,  even  when  it  is  not  there.  While 
undenway,  the  anycast  address  scheme  insures  that  mobile  tactical  users  can 
maintain  at  least  one  network  interface  at  all  times,  therefore  maintaining 
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network  connectivity.  It  also  overcomes  the  need  to  update  and/or  change  a 
unit's  IP  address  just  because  it  changed  its  network  interface  (e.g.,  moves  from 
one  NCTAMS  to  another).  While  inport,  and  directly  connected  to  the  DISN,  the 
sharing  of  anycast  addresses  is  discontinued  (by  a  corn-shift  message)  and  the 
tactical  unit  regains  sole  ownership  of  its  unique  IP  address. 

A  simple  routing  scheme  for  mobile  units  can  be  developed  using  just  the 
mobile  IP  construct  previously  outlined.  However,  this  would  force  all  message 
datagrams  to  be  initially  routed  to  the  unit's  home  agent  (homeport 
NAVCOMSTA).  The  home  agent  would  then  retransmit  these  datagrams  to 
wherever  the  mobile  unit  was  physically  located  at  the  time  (foreign  agent).  The 
anycast  address  scheme  minimizes  this  network  routing  overhead  by  allowing 
several  interfaces  to  advertise  the  IP  address  of  a  mobile  unit.  For  instance, 
message  datagrams  from  an  originator  located  in  Japan  wishing  to  send  a 
message  to  HOUSTON  should  not  (normally)  have  to  travel  all  the  way  to  the 
HOUSTON'S  homeport  NAVCOMSTA  (in  San  Diego,  CA),  to  then  be  rerouted  to 
NCTAMS  WESTPAC  for  broadcast.  Ideally  in  this  case,  the  nearest  interface 
will  be  NCTAMS  WESTPAC,  who  maintains  direct  GBS  connectivity  with 
HOUSTON. 

In  another  example,  SPRUANCE  enters  the  Mediterranean  and  shifts 
communication  guard  from  NCTAMS  LANT  to  NCTAMS  MED.  A  com-shift 
message  informs  NCTAMS  LANT  to  drop  SPRUANCE's  IP  address  from  their 
routers,  and  NCTAMS  MED  to  add  it  to  theirs.  Now  all  DMS  datagrams  intended 
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for  SPRUANCE  are  routed  via  the  DISN  to  either  NAVCOMSTA  Mayport  (who 
then  tunnels  them  to  NCTAMS  MED)  or  directly  to  NCTAMS  MED  for  GBS 
broadcast.  Anycast  addressing  allows  NAVCOMSTA  Mayport  to  maintain  a 
continuous  network  interface  for  SPRUANCE  messages,  even  during  NCTAMS 
transitioning  periods. 


3.  DMS  Broadcast  to  an  Embarked  Unit 

Message  traffic  addressed  to  an  embarked  unit  (e.g.,  COMDESRON  2)  is 
routed  in  a  similar  manner.  The  embarked  unit  is  responsible  for  initializing  an 
anycast  address  in  conjunction  with  their  host  unit.  There  are  two  methods  by 
which  this  can  be  accomplished: 

•  The  embarked  unit  notifies  its  homeport  NAVCOMSTA  of  which  host  unit 
it  will  be  underway  in.  The  embarked  unit  then  shares  the  anycast 
address  of  its  host  unit,  and  does  not  have  to  add  its  own  IP  to  the 
NCTAMS  routers.  This  helps  in  the  reduction  of  routing  table  size  and 
update  frequency.  However,  the  IP  address  of  the  embarked  unit  must  be 
integrated  into  the  routing  tables  of  the  host  platform,  who  segregates  and 
internally  routes  messages  to  the  embarked  unit.  Embarked  units 
assigned  to  ships  with  a  single  MTA  ships  would  benefit  from  this  method. 

•  The  embarked  unit  acts  like  a  stand  alone  entity  and  sends  messages  to 
update  both  their  NAVCOMSTA  and  NCTAMS  routers.  A  key  advantage 
is  the  ability  to  individually  receive  traffic  if  the  host  unit  can  support 
multiple  MTAs,  each  linked  to  a  GBS  receiver.  This  configuration  is  most 
appropriate  for  larger  platforms  such  as  command  ships,  aircraft  carriers 
and  amphibious  vessels. 

In  either  case,  all  subsequent  message  routing  instructions  are  delineated 
by  corn-shift  messages.  A  corn-shift  message  from  a  tactical  unit  to  a  NCTAMS 
can  include  the  IP  addresses  (and  email  addresses)  of  all  embarked  units  (e.g., 
helicopter  squadrons,  meteorological  detachments,  embarked  staffs  and  marine 
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detachments).  This  concept  allows  embarked  units  to  maintain  the  same  IP 
address  regardless  of  whether  they're  in  port  or  at  sea. 

In  the  scenario,  DMS  messages  addressed  to  COMDESRON  2  are  routed 
to  either  NAVCOMSTA  Norfolk  (who  then  tunnels  them  to  NCTAMS  MED)  or 
directly  to  NCTAMS  MED,  who  accepts  receipt  and  queues  the  messages  for 
GBS  broadcast  to  SPRUANCE.  SPRUANCE's  MTA  then  sorts  and  routes  the 
messages  to  COMDESRON  2's  DA. 

4.  Shipboard  Message  Flow 

The  GBS  broadcast,  transmitted  at  1.544  Mbps  or  23  Mbps  depending  on 
CINC  requirements  and  the  tactical  unit's  geographic  position,  is  captured  by  one 
or  more  small  shipboard  receive  antennas'*.  The  ATM  datastream,  specifically 
the  channel  carrying  DMS  traffic,  is  demultiplexed  and  decrypted.  The  GBS 
terminal  accepts  only  those  data  cells  addressed  to  the  unit,  discarding  the  rest. 
In  the  case  of  DMS,  the  error-corrected  and  in-sequence  message  datastream  is 
routed  to  the  ship's  MTA  (most  likely  the  current  NAVMACS  II)  for  X.400  address 
profiling,  and  routing  within  the  ship's  network  to  the  intended  recipient's  DA. 

The  first  datagrams  received  by  the  MTA  initiate  a  CMTP-based  message 
transfer  session.  Use  of  the  CMTP  protocol  allows  the  recipient  (shipboard) 

MTA  to  accept  the  datagrams  without  a  PI  level  connection  between  itself  and 
the  originating  (NCTAMS')  MTA.  The  NAVMACS  II  can  also  be  configured  to 

"Most  certainly,  more  than  one  antenna,  linked  by  a  shipboard  LAN,  is 
necessary  to  improve  signal  reception,  system  survivability,  reduce  topside 
placement  constraints  and  allow  for  multiple  MTA  configurations. 
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transmit  message  receipt/read  confirmations  over  a  duplex  link,  if  required.  The 
ability  of  NAVMACS  II  to  act  as  a  DMS  MTA  was  proven  during  tests  aboard 
USS  KITTY  HAWK  (CV  63)  in  conjunction  with  the  Joint  Warrior  Interoperability 
Demonstration  1995  (JWID  95)  [Ref.  19].  Figure  9  depicts  the  proposed 
shipboard  data  and  DMS  message  flow. 


Figure  9.  Shipboard  Data/Message  Flow. 


D.  DOCTRINAL  ASPECTS:  SMART  PUSH,  USER  PULL 

The  proposed  system  allows  for  a  more  robust  management  of  tactical 
broadcast  messaging.  For  instance,  along  with  the  shift  in  communication  guard 
and  DMS  message  acknowledgment,  the  NAVCOMSTAs  and  NCTAMS  are 
tasked  by  each  unit  of  any  special  priorities,  long-term  storage  needs  and  GBS 
broadcast  requirements.  These  instructions  act  as  the  "smart  warrior  pull"  aspect 
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of  this  tactical  DMS  concept.®  Proper  application  of  broadcast,  computer,  email 
and  network  technologies  can  greatly  enhance  the  tactical  user's  ability  to 
specifically  tailor  their  data  communications  service  needs,  regardless  of  how 
they  connect  to  the  network.  Some  examples  of  this  concept  are  outlined  below. 
References  to  the  given  operational  scenario  are  delineated  in  italics. 

1 .  Specific  Times  to  T ransmit  Messages 

DMS  guidelines  call  for  at  least  ten  days  of  message  storage  capacity. 

This  needs  to  be  higher,  especially  for  those  units  with  irregular  communications 
needs. 

HOUSTON,  due  to  operational  necessity,  has  irregular  communication 
black-outs.  She  has  instructed  NCTAMS  WESTPAC  to  hold  all  IMMEDIATE  and 
below  DMS  traffic  for  bulk  GBS  transmission  at  preset  times  or  after  she  has 
contacted  them.  Notifications  of  FLASH  traffic  (and  higher)  are  made  using 
current  systems  (e.g.,  HF,  VLF).  The  high  priority  messages  are  transmitted 
continuously  over  GBS  until  acknowledgment  of  receipt  (verbal  or  message  or 
both)  is  received  at  the  NCTAMS. 

ALTAIR,  whose  operational  message  traffic  requirements  are  much  lower 
than  most  other  units,  has  all  DMS  traffic  broadcast  to  her  four  times  daily. 
GETTYSBURG,  SPRUANCE  and  COMDESRON  2  have  all  their  DMS  traffic 

®  User-defined  messaging  parameters  are  not  a  new  concept.  However, 
continued  application  of  Internet-based  technologies,  such  as  WWW  and  email 
in  the  tactical  environment,  offers  several  new  possibilites  on  how  those 
parameters  are  defined,  exchanged  and  updated  [Ref.  8]. 
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queued  and  transmitted  over  GBS  upon  receipt  at  NCTAMS  LANT  and  NCTAMS 
MED. 

2.  Receipt  Confirmations 

Tactical  users  will  dictate  how  receipt  of  messages  will  be  accomplished 
(e.g.,  in  bulk).  This  can  be  done  over  duplex  links,  with  the  tactical  unit 
transmitting  a  database  of  received  message  date-time  groups  twice  daily. 
Messages  not  confirmed  as  received  can  be  automatically  retransmitted  by  the 
GBS  system.  Confirmation  of  message  receipt  and  read  by  the  tactical  recipient 
is  transmitted  over  duplex  DMS  links  back  to  the  originator,  if  required. 

COMDESRON  2,  expecting  a  heavy  DMS  traffic  load  during  operations  in 
the  Adriatic  Sea,  instructs  NCTAMS  MED  that  only  IMMEDIATE  and  above 
precedence  messages  will  be  confirmed  as  received.  Receipts  will  be 
accomplished  in  bulk  format,  three  times  daily.  Originators  of  all  other  DMS 
traffic  will  receive  a  preformatted  message  stating  that  "your  message  addressed 
to  COMDESRON  2  has  been  transmitted  over  GBS.  Due  to  operational 
constraints  no  direct  acknowledgment  of  receipt  by  COMDESRON  2  is 
expected". 

3.  Routing  Instructions  for  High  Priority  Messages 

This  concept  allows  the  tactical  user  to  tailor  the  transmission  of 
high-priority  messages.  For  example,  all  FLASH  traffic  can  be  sent  over  GBS 
and/or  duplex  systems  continuously  until  receipt  is  acknowledged. 
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GETTYSBURG,  expecting  notification  of  possible  surge-deployment  to  the 
Caribbean,  has  instructed  NCTAMS  LANT  to  route  all  FLASH  traffic  over  both 
GBS  and  duplex  systems  to  improve  probability  and  speed  of  reception. 

4.  Storage  of  Messages  With  Certain  Header  Data 

NAVCOMSTA  and  NCTAMS  local  message  stores  can  hold  specified 
message  types/addresses  until  the  tactical  unit  can  "log  in"  to  the  DISN  and 
download  them.  This  concept  closely  follows  the  Navy's  current  "gateguard" 
communication  architecture. 

GETTYSBURG  instructs  NCTAMS  LANT  to  hold  all  ROUTINE  DMS  traffic 
during  their  2  day  transit  from  Mayport,  FL  to  Norfolk,  VA. 

E.  ADVANTAGES 

The  proposed  DMS  broadcast  over  GBS  (DMS/GBS)  concept  offers 
several  advantages,  each  presented  below. 

1.  Simplicity 

This  concept  outlines  a  simple  yet  scaleable  broadcast  capability  which 
can  be  integrated  into  other  tactical  DMS  Implementation  efforts.  It  resolves  the 
problem  of  TCP  connectivity  over  a  connectionless  link,  overcomes  the 
mobile-user  restrictions  of  the  current  IP  protocol,  while  also  addressing  the 
connection  needs  of  the  X.400  application  protocols.  The  only  new  development 
required  is  a  completion  of  the  CMTP  to  replace  the  current  P1  protocol. 
Moreover,  it  outlines  a  new,  compatible  method  of  TCP/IP-based  messaging 
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over  the  existing  DISN  infrastructure  that  accommodates  the  unique  limitations 
and  needs  of  the  mobile  user. 

2.  Performance 

DMS/GBS  offers  an  order  of  magnitude  jump  in  broadcast  technology 
over  the  existing  Fleet  Broadcast  system,  one  that  also  integrates  mandated 
DMS  interoperability.  Whether  the  data  is  transmitted  at  1 .544Mbps  or  23Mbps 
the  jump  in  throughput  performance  makes  GBS  a  logical  choice  for  large  scale 
tactical,  data  dissemination.  Appendix  C  depicts  a  comparison  of  data 
throughput  performance  using  various  military  communications  system, 
highlighting  the  gain  in  message  delivery  speed  offered  by  GBS. 

3.  Security 

There  is  no  reduction  of  MISSI  security  standards.  Datagrams  (DMS 
messages)  are  not  decrypted  by  the  intermediate  interfaces,  only  repackaged 
and  rerouted.  Transmission  over  the  GBS,  with  bulk  encryption  of  the 
datastream,  adds  another  layer  of  security  to  DMS  message  dissemination. 

4.  Relief  of  MILSATCOM  Burdens 

DMS/GBS  implementation  offers  a  reduction  of  message  traffic 
congestion  over  the  current  duplex  MILSATCOM  systems.  With  the  vast 
majority  of  operational  traffic  to  tactical  units  handled  by  the  DMS/GBS  system, 
duplex  systems  can  better  accommodate  high-priority  messaging,  GBS  user 
service  requests  and  shore-bound  DMS  traffic  from  the  tactical  units. 
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6. 


Near  and  Long-Term  Utility 


The  proposed  system  offers  a  near-term  tactical  DMS  utility  while  more 
robust  duplex  links  are  developed.  It  also  identifies  the  frame-work  for  a 
long-term  DMS  broadcast  link.  Furthermore,  the  routing  and  transport  concepts 
applied  in  this  system  (mobile  IP,  anycast,  IPv6)  can  be  adapted  to  any  IP  routed 
data  network  in  order  to  achieve  a  mobile  user  connectivity. 

F.  LIMITATIONS 

There  are  two  primary  limitations  imposed  by  this  concept.  However,  the 
limitations  apply  to  all  other  current  tactical  DMS  proposals  as  well.  Neither 
limitation  affects  the  scaleability,  connectivity  or  capability  of  service,  only  the 
elements  of  service  available  to  the  tactical  DMS  user. 

1 .  Receipt  Acknowledgments 

Under  the  DMS/GBS  concept,  immediate  acknowledgment  of  message 
receipt  or  read  by  the  intended  recipient  is  not  available.  Only  receipt/queuing 
acknowledgments  by  the  responsible  NCTAMS  are  immediately  returned  to  the 
originator.  However,  delayed  acknowledgments  can  be  initiated  by  the  tactical 
unit  via  a  duplex  DMS  link. 

2.  X.500 

The  ability  to  immediately  search  the  distributed  X.500  directory  of  X.400 
addresses  and  user  data  cannot  be  accomplished  over  the  proposed  system. 
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However,  tactical  units  can  download  the  current  X.500  database  (or  subsets  of 
it)  prior  to  getting  underway.  Once  at  sea,  updates  to  the  database  can  be 
requested  via  duplex  links  and  transmitted  to  the  tactical  unit  via  the  GBS 
broadcast. 

G.  CONCEPT  SUMMARY 

In  summary,  the  challenge  of  broadcast  DMS  extension  to  the  mobile 
tactical  unit  is  resolved  using  new  routing  techniques  and  high  throughput 
broadcast  links.  When  underway,  units  maintain  anycast  addresses  with  their 
homeport  NAVCOMSTAs  and  with  the  individual  NCTAMS  accepting  traffic  for 
them.  DMS  messages  addressed  to  a  tactical  unit  are  sent  to  the  nearest 
interface  holding  that  unit's  anycast  address.  If  the  nearest  interface  is  the  ship's 
homeport  NAVCOMSTA,  and  the  ship  is  out  of  homeport,  then  the  message 
datagrams  are  encapsulated  and  rerouted  by  the  NAVCOMSTA  to  the  NCTAMS. 
If  the  nearest  interface  is  the  NCTAMS  itself,  then  no  further  routing  is  required; 
receipt  of  the  message  is  acknowledged  and  it  is  queued  for  GBS  transmission. 
The  transport  and  application  layer  protocol  problems,  outlined  in  Chapter  I  and 
in  the  introduction  of  this  Chapter,  are  resolved  by  having  the  NCTAMS'  routers 
conduct  all  error  checking,  retransmit  requests  and  datagram  sequencing  prior  to 
queuing  message  datagrams  for  ATM  broadcast  over  GBS.  The  application  of 
CMTP  protocols  at  the  NCTAMS  and  shipboard  MTAs  allow  DMS  datagrams  to 
be  successfully  transmitted  over  a  simplex  link.  The  result  is  an  in-sequence  and 
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error-free  DMS  datastream  transmitted  over  a  high-speed  simplex  link  to  the 
tactical  user.  ® 

The  proposed  system  relies  on  the  integration  of  IPv6,  CMTP  and  the  use 
of  mobile  IP  constructs  within  the  DISN  environment.  There  are  also  some 
hardware,  infrastructure  and  management  issues  which  must  be  concluded 
before  this  system  can  be  implemented.  These  issues,  and  proposals  for  their 
resolution,  are  the  focus  of  the  following  chapter. 


®The  concept  of  using  an  intermediary  router  which  maintains  a  duplex  link 
with  one  node  and  a  simplex  link  with  another  was  originally  developed  for  use  in 
network  security.  This  concept  allows  unclassified  nodes  to  pass  traffic  to 
classified  nodes,  but  stops  any  transfer  of  data  from  a  secure  node  to  a 
unclassified  node.  The  intermediary  router  receives  datagrams  from  a 
unclassified  node  via  a  duplex  link,  generates  acknowledgments  to  the  sender, 
repackages  the  datagrams  with  error  correction  and  sends  them  out  a  separate 
simplex  link  to  the  classified  recipient.  In  this  manner  the  unclassified  node  has 
no  direct  access  to  the  classified  network  but  can  still  pass  data  to  it;  while  the 
classified  nodes  cannot  transmit  to  the  unclassified  network. 
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V.  RECOMMENDATIONS  AND  CONCLUSIONS 


The  previous  chapter  outlines  a  concept  of  operations  for  a  high  data-rate, 
DMS-capable  broadcast  service.  The  actual  implementation  of  this  concept 
relies  heavily  on  the  application  of  recent  technologies  and  the  resolution  of 
specific  issues  within  the  developing  DISN  framework.  An  information 
distribution  system,  such  as  the  proposed  DMS/GBS  system,  is  oniy  as  robust 
and  effective  as  the  underlying  network  which  supports  it  (DISN).  Improvements, 
therefore,  in  the  effectiveness  of  the  common  network  benefit  all  subsystems 
which  rely  on  it.  The  proper  design  of  a  supporting  network  should  be  the  first 
priority  in  the  restructuring  of  the  military's  information  distribution  system. 
Furthermore,  this  design  must  include  data  distribution  standards  to  which  all 
network  clients  must  conform.  It  is  no  longer  fiscally  or  technologically  effective 
or  efficient  to  design  and  implement  independent  information  subsystems  only  to 
later  force  their  interoperability  over  a  network.  This  "network-centric"  approach 
to  information  distribution  systems  provides  the  greatest  freedom  for  subsystem 
design  while  simplifying  any  future  network  and  subsystem  expansion  [Ref.  8]. 

A.  NEAR-TERM  RECOMMENDATIONS 

The  following  recommendations  should  be  viewed  as  a  list  of  technologies 
which  can  be  applied  to  expand  the  usability,  scaleability  and  performance  of  the 
overall  DISN.  These  specific  recommendations  can  be  implemented  in  the 
near-term  to  improve  the  DISN  without  significant  DoD  development  or  network 
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restructuring.  The  generation  of  a  comprehensive  set  of  requirements  for 
implementation  of  the  proposed  DMS/GBS  system  is  left  for  a  follow-on  effort. 

1.  Infrastructure:  World-Wide  GBS  Coverage 

There  is  currently  no  better  alternative  for  expanding  the  information 
broadcast  capabilities  of  military  communications  than  with  the  GBS.  The 
military's  requirement  to  project  a  presence  anywhere  in  the  world  mandates  that 
its  supporting  information  infrastructure  be  based  on  global  connectivity.  The 
modification  and  launch  of  all  three  GBS-capable  UFO  satellites  (#8,  #9,  #10) 
should  be  considered  a  minimum  first  step  in  establishing  a  very  critical  aspect  of 
this  capability.  A  initial  assessment  of  GBS  as  a  dissemination  system  for  DMS 
can  be  made  using  the  current  testbed  GBS  (CONUS-based)  system  operated 
by  the  NRO. 

2.  Accelerated  Development  /  Fielding  of  CMTP 

The  Connectionless  Message  Transfer  Protocol  promises  to  alleviate  X.400 
of  its  restriction  to  duplex-only  links.  Until  this  protocol  is  fully  developed,  the  US 
Navy  Fleet  Broadcast  subsystem  (albeit,  all  broadcast  systems)  will  remain 
unable  to  transmit  X.400  messages  without  extensive  format  conversion  and  a 
severe  reduction  of  the  tactical  user's  DMS  elements  of  service.  Delays  in  the 
development  and  application  of  CMTP  translate  to  a  continued  degradation  in 
DMS  connectivity  to  the  tactical  environment. 
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3.  Application  of  IPv6  on  the  DISN 

The  proposed  DMS/GBS  system  relies  heavily  on  IPv6's  anycast  address 
scheme.  However,  IPv6  should  be  applied  to  the  DISN  architecture  not  because 
it  is  required  by  any  one  system  or  proposed  concept,  but  because  it  supplies  a 
vastly  improved  routing  and  addressing  structure  to  a  network.  IPv6  therefore 
allows  for  extended  network  growth  and  the  application  of  more  robust 
information  management  schemes.  If  for  no  other  reason  IPv6  should  be 
implemented  on  the  DISN  for  its  expanded  address  space  and  multicast 
capabilities. 

4.  Application  of  the  Mobile  IP  Concept 

In  much  the  same  manner  as  IPv6,  Mobile  IP  constitutes  a  commercially 
developed,  backward-compatible  concept  which  expands  network  capability 
without  affecting  the  overall  network  structure.  As  military  data  communications 
move  toward  the  DISN  vision.  Mobile  IP  offers  a  near-term,  relatively  simple,  yet 
effective  method  of  integrating  the  highly  mobile  subscriber  without  development 
of  proprietary  protocols  or  subnets.  Implementation  and  testing  of  this  concept 
on  the  Navy's  NCP  II  can  be  made  with  little  or  no  disruption  to  operational 
message  traffic. 

5.  NCTAMS  as  DMS  and  GBS  Theater  Management  Centers 

As  theater-wide  routing  and  switching  centers,  NCTAMS  already  provide  a 
key  link  between  the  Navy's  information  networks  and  the  warfighter.  If  DMS 
and  GBS  are  extended  as  planned  to  the  warfighter  arena,  they  should  be 
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placed  under  the  operational  control  of  the  theater  CINCs.  Uniting  these 
subsystems  and  their  theater-level  management  operations  under  one  NCTAMS 
roof  means  not  having  to  add  new  networking  layers  to  a  CINCs  communication 
infrastructure. 

B.  LONG-TERM  RECOMMENDATIONS 

It  can  be  effectively  argued  that  the  most  important  aspects  in  the 
development  and  implementation  of  any  information  system  are  a  clear  strategic 
vision  of  that  system's  intended  application  and  the  realization  that  continual 
improvement  as  a  function  of  the  architecture  must  be  incorporated  into  the  initial 
design.  However,  these  design  issues  are  probably  the  most  difficult  to  detail  as 
well.  This  is  especially  true  in  the  case  of  the  DISN,  GBS  and  DMS,  where  the 
system  has  already  been  designed  and  implementation  has  begun.  Therefore 
the  following  long-term  recommendations  are  of  a  more  technological  rather  than 
design  nature.  While  these  recommendations  are  founded  in  the  improvement  of 
the  current  DMS  and  GBS,  they  are  not  entirely  based  on  what  is  required  to 
implement  the  proposed  DMS/GBS  system.  They  should  be  seen  as  general 
comments  and  opinions  on  what  may  assist  in  providing  a  robust,  long-term 

military  data  communication  infrastructure. 

•  Continued  expansion  of  the  GBS  earth  coverage.  The  current  three 
satellite  constellation  constitutes  the  minimum  required;  it  does  not 
provide  for  system  redundancy  or  polar  coverage. 

•  Integration  of  the  (still  under  development)  Low  Earth  Orbit 
Satellites  (LEOS).  This  commercially  developed  satellite-based  system 
is  aimed  at  world-wide  voice  and  data  connectivity.  These  systems 
represent  a  (promised)  large-scale  upgrade  in  world-wide  networking  and 
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information  distribution.  DoD  should  prepare  integration  plans  and  system 
implementation  analysis  before,  not  after,  these  systems  are  placed  in 
service.  Anticipation  of  this  capability  may  reduce  the  initial  lag  in 
effective  information  management  integration  which  has  challenged  the 
GBS. 

•  Maintain  the  VLF,  HF  and  UHF  systems  as  back-ups.  They  are  paid 
for,  in-place  and  operational.  Why  limit  the  channels  of  dissemination?  HF 
systems  remain  the  only  non-satellite,  long-haul  communication  link,  and 
VLF  stands  as  the  only  means  to  communicate  with  submerged 
submarines.  As  such,  the  VLF  and  HF  media  act  as  needed 
complements,  not  competition,  to  satellite-based  systems  and  should  be 
integrated  into  the  DISN  infrastructure  [Ref.  8]. 

•  Maintain  (expand  on)  an  X.400  to  SMTP  connectivity.  Simple 

Mail  Transfer  Protocol  (SMTP)  is  the  standard  for  email  communications 
within  the  commercial  Internet.  DMS  users  will  require  connectivity  to 
email  systems  outside  the  DoD,  and  it  appears  that  there  will  be  very  little 
X.400  market  penetration  into  the  commercial  world.  Furthermore,  as 
development  of  SMTP  and  associated  email  protocols  continues  in  the 
commercial  arena,  DoD  may  well  have  to  reconsider  its  adoption  of  X.400. 


C.  AREAS  REQUIRING  FURTHER  STUDY 

This  thesis  presented  a  general  concept  of  operations  for  a  DMS/GBS 
broadcast  system.  The  next  logical  step  In  the  development  of  this  concept  is 
the  accurate  modeling  and  simulation  and  prototyping  of  the  proposed  system. 
Several  individual  technologies  ( e.g.,  IPv6,  Mobile  IP,  GBS,  CMTP)  were 
incorporated  in  order  to  arrive  at  the  final  system  concept.  Obviously,  continued 
analysis  of  each  individual  technology  and  its  application  to  the  military 
communications  environment  is  required.  In  the  case  of  the  proposed  DMS/GBS 
concept,  the  simulation  and  integration  of  the  several  individual  parts  should  be 
the  modeler's  first  priority.  Accurate  system  simulation,  if  even  possible,  may 
well  prove  a  secondary  fallout  of  what  is  learned  by  the  efforts  undertaken  to 
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integrate  these  individual  technologies.  Specifically,  any  modeling/simulation 

efforts  based  on  the  proposed  concept  should: 

•  Test  the  NCR's  ability  to  act  as  "intermediary"  TCP/IP  relay  system 
which  ties  together  duplex  and  simplex  links.  What  hardware,  software 
and  management  are  required  to  enact  this  integration?  What  time  delay 
and  data  overhead  is  added? 

•  Test  the  general  scaleability  of  the  proposed  anycast  IP  concept, 
specifically  at  the  NCTAMS  router.  How  many  users  can  effectively  be 
supported  by  one  NCTAMS  router?  Based  on  delivery  times,  scaleability 
and  ease  of  use,  is  the  concept  better  than  re-assignment  of  IP  addresses 
to  mobile  units? 

•  Evaluate  the  usability  of  Mobile  IP  in  a  dynamic  tactical 
environment.  What  constraints  or  limitations  are  there  in  the  scaleability 
of  this  concept  to  an  entire  fleet  or  Navy?  What  data  delivery  delays  are 
introduced?  What  hardware/software  modifications  are  required  by  the 
home  and  foreign  agents?  What  are  the  security  considerations? 

•  Test  the  capabilities  and  limitations  of  CMTP  (when  available).  Does 
it  really  allow  a  simplex  MTA  connectivity?  Can  it  coexist  with  the 
standard  P1  protocol?  What  quality  of  service  limitations  are  imposed? 
How  can  the  capability  be  best  implemented  and  managed? 

•  Examine  what  hardware/software  modifications  are  required  to 
integrate  the  GBS  datastream  and  the  shipboard  MTA  (NAVMACS?). 

Are  (low  data-rate)  back  channels  required  to  effect  a  reliable  link?  What 
are  the  effects  and  consequences  of  unexpected  link  disruption  caused  by 
atmospheric  disturbances  on  message  delivery? 

•  Examine  addressing  issues.  Operational  messages  are  traditionally 
sent  to  a  unit,  not  an  individual.  What  doctrinal  changes  are  required  (if 
any)  to  support,  manage  and  exploit  (limit?)  the  addressing  capabilities  of 
DMS? 

•  Outline  network  management.  Develop  a  comprehensive  (end-to-end) 
plan  for  automated  network  management,  to  include  fault  location, 
maintenance  and  restoration.  Model  system  performance  under  stress 
(jamming,  node  destruction,  peak  traffic  loading,  and  environmental 
factors). 
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While  not  the  focus  of  this  thesis,  it  should  be  noted  that  there  remain 
several  alternatives  and  unanswered  issues  in  the  seamless  extension  of  duplex 
tactical  DMS.  These  varied  alternatives,  which  encompass  both  technological 
and  information  management  aspects,  require  further  exploration,  analysis  and 

testing.  The  issues  include  such  topics  as: 

•  Modeling  and  testing  of  the  proposed  MFI  (Multi-Function 
Interpreter)  concept.  What  overhead,  errors  and  time  delays  are  added 
to  the  system  by  its  use?  How  does  the  reduction  in  DMS  elements  of 
service  caused  by  the  MFI  effect  the  tactical  user  and/or  the  message 
originator? 

•  Alternatives  to  the  continued  use  of  low-rate  MILSATCOM  systems 
for  DMS  tactical  connectivity.  What  military  or  commercial 
communications  systems  are  in  development  which  can  increase  DMS 
connectivity  and  system  availability  at  the  tactical  level? 

•  DMS  personal  messaging.  DMS  extends  messaging  capabilities  down 
to  a  personal,  vice  the  traditional,  unit  level.  How  will  this  affect  the  overall 
operational  DMS?  What  doctrinal  and  operational  (security?)  implications 
are  involved? 


D.  CONCLUSIONS 

DoD  messaging  is  moving  to  the  Defense  Message  System.  Ultimately, 
DMS  will  be  implemented  in  all  DoD  environments:  tactical,  strategic,  fixed  and 
mobile.  However,  while  DMS  efforts  are  aimed  at  providing  multimedia 
messaging  capabilities,  the  networks  used  to  pass  these  messages  are  not 
being  expanded  to  meet  the  new  requirements.  The  Navy's  Fleet  Broadcast 
subsystem  is  particularly  ill-equipped  to  handle  DMS  traffic.  Broadcast  systems 
are,  however,  an  integral  and,  with  GBS,  a  growing  part  of  modern  military 
communications,  especially  during  covert  or  emission  controlled  (EMCON) 
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operations.  The  Navy's  Fleet  broadcast  must  be  modernized  if  it  is  to  become  a 
seamless  extension  of  the  DMS  infrastructure  into  the  tactical  environment. 

At  the  same  time  the  US  military  is  developing  a  new  satellite-based  data 
dissemination  system  known  as  GBS.  Early  applications  of  GBS  are  aimed  at 
theater-wide  database  updates  and  video  broadcast.  However,  this  system  can 
also  be  used  as  a  new  high-throughput  message  dissemination  service.  The 
GBS  in  effect  becomes  a  new  Fleet  Broadcast  subsystem.  In  this  manner,  not 
only  is  the  broadcast  capability  of  DMS  expanded,  but  the  overall  load  on  duplex 
MILSATCOM  systems  is  reduced. 

This  thesis  attempted  to  present  one  possible  method  of  integrating  the 
DMS  and  GBS  systems.  This  effort  was  undertaken  in  order  to  explore  how  the 
DMS  messaging  capability  could  be  extended  to  the  mobile,  tactical  user  via  a 
new,  more  robust  broadcast  subsystem. 
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APPENDIX  A.  OPEN  SYSTEMS  INTERCONNECTION  (OSI) 
REFERENCE  MODEL.  AFTER  REF  [21]. 


OSI  LAYER  PRIMARY  FUNCTIONS 


7 


6 


5 


4 


3 


2 


1 


application  layer 


presentation  layer 


session  layer 


transport  layer 


network  layer 


data  link  layer 


physical  layer 


File  transfers 
Electronic  mail 
Databases 

Syntax  conversion 
Data  structure 


■> 


X.400 


Applications  /  programs 
Session  control 


Quality  of  network  service 
End-to-end  integrity 
Network  service  definition 


Network  operations 
Switching  and  routing 
Network  interfaces 


^TCP/ 

IP** 


Line  integrity 
Error  checking 
Flow  control 


Timing  and  encoding 
Physical  connectors 
Cables,  Wires,  Fiber 


**  Approximate  Mapping 


APPENDIX  B.  X.400  ENVIRONMENTS,  COMPONENTS 
AND  INTERFACE  PROTOCOLS 
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MTA:  Message  T ransfer  Agent 
DA:  User  Agent 
MHS;  Message  Handling  System 
MTS:  Message  Transfer  System 
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APPENDIX  C.  DATA  THROUGHPUT  COMPARISONS  OF 
VARIOUS  SYSTEMS.  AFTER  REF  [20]. 


Representative  System  And  Throughput 


75  bps 

2.4  Kbps 

512  Kbps 

llllllllllllll 

23  Mbps 

Current 

FLTBCST 

MILSTAR 

&UFO 

(duplex) 

NIPRNET 

SIPRNET 

GBS@ 

20OOnm 

SOOnm 

ATO  @ 

1.1  Mbytes 

32.6  hours 

1.02  hours 

17.2  sec 

5.71  sec 

sec 

T-Hawk 

MDU@ 

30kbytes 

53  min 

100  sec 

.46  sec 

.17  sec 

.01  sec 

Text  Only  * 
DMS  msg 

7.5  Kbytes 

13.33  min 

25  sec 

.117  sec 

.038  sec 

.002  sec 

-All  transmission  times  calculated  using: 

[8  data  bits  per  byte  *  msg  size]  /  system  throughput 

-Message  sizes  are  strictly  information  content  and  do  not  account  for 
encryption,  error  correction,  enveloping  or  transmission  protocol  overhead  bits, 
which  can  vary  depending  on  transmission  system  used. 

*  Based  on  three  times  the  current  AUTODIN  average  message  size  (see 
Chapter  I),  no  multimedia  attachments. 
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